Thursday, June 14, 2007
Thursday, May 24, 2007
Perfect Pairing: OpenGL Cards, Dual Monitors
In our previous two sections, we learned that OpenGL graphics card performance on real applications is only tangentially related to theoretical performance metrics like triangles per second or fill rate. Rather, the ability to adapt to the fast changing requirements of most OpenGL applications is what makes an OpenGL graphics card truly useful. In short, OpenGL is an agility course, not a sprint,
That work done, in this review, we shift our attention to how each card performs while driving two monitors. As we'll see, this involves both hardware and software decisions regarding how a board allocates its collective OpenGL horsepower between two open monitors. We'll also see a dramatic range in performance degradation when dual monitors are running on our respective boards.
Speaking of boards, let's get reacquainted with the boards in this review, which includes the 3Dlabs Wildcat III 6110 ($1,500 - $2,000 street), ATI's FireGL 8800 ($599 street), Nvidia's Quadro4 900 ($1,500 street) and Nvidia's Quadro4 750 ($995 street). We included an extensive features table in the first segment. Note that we used the same driver revisions as in the first two story segments for consistency, and we indicate those versions in the first segment. There may be newer drivers released in the past month.
Table 1, Dual Monitor Support All Segments Combined All Segments Combined EDA DCC FINANCE GIS/Geo One 82% 82% 70% 88% 85% 81% Two 17% 16% 30% 10% 15% 19% Three 1% 2% 0% 0% 0% 0% Four 1% 0% 0% 3% 0% 0% Source: IDC, 2001
Dual monitor support started appearing on OpenGL graphics cards several product generations ago, but actual dual monitor use is still fairly modest, at least in 2001, when IDC performed the study shown in Table 1. That said, recent price breaks on LCD monitors, and ever faster computers and graphics cards, makes dual monitor use much more attractive today than in the past. All three graphics card vendors felt that dual monitor use would increase appreciably over the next few years.
With dual monitor use modest but growing, it appeared that benchmarking performance under dual monitor use was, or would soon be, important for those making buying decisions. The question was, how to test?
Note that the IDC study didn't describe how users were actually configuring their applications over the dual monitors. Specifically, we don't know what percentage of usage was spanning one application over both monitors, and which scenarios used each monitor for a different application. SPEC tests, all devised for single monitor application, and very well defined for that type of tests, provided little help except when used in concert with other applications.
After some early experimentation, we arrived at three scenarios that likely represent a significant percentage of actual dual monitor use. The first two assumed that different applications are being run in the primary and secondary monitor. We assumed that an engineer running Pro/Engineer in one monitor might run Internet Explorer in the other, or perhaps a second OpenGL program to assist their development efforts. To test performance under this scenario, we enabled the second monitor, opened up the second application, and ran the benchmark test in the primary monitor. Obviously, choosing which application(s) would be open in the second monitor was a key test criteria.
An important point to make here is that for most of our dual monitor testing we weren't attempting to run intensive workloads on both monitors simultaneously, though we did have one section of testing with dual, simultaneous workloads measured. Most of our testing involved loading different types of applications for display on the second monitor, with a model loaded to engage the card's OpenGL facilities when appropriate, but without initiating active workloads.
When running an OpenGL application on the second monitor, it simulates a designer creating a model in one application, then loading it in another. When a non-OpenGL application was loaded, it simulates an e-mail or word processor open in the second window, with an active design in the primary window. .
Before selecting which programs would be open in the second monitor, we experimented with a variety of applications, including Internet Explorer, Microsoft Word and PhotoShop, finding that the boards generally responded in one of two ways (at least in our tests with components of the SPECviewperf 6.1.2 suite run on the primary monitor).
First, the Wildcat and the FireGL boards seemed to react similarly irrespective of the type of application, reacting more to the presence of a second open monitor than the type of application. In contrast, the two Nvidia cards reacted very differently depending upon the type of application running in the second window. Here are some of our results.
---------------------------------------
Single monitor AWadvs-04 Weighted Geometric Mean = 304.2
Lightwave (secondary app) AWadvs-04 Weighted Geometric Mean = 156.8
SolidWorks (secondary app) AWadvs-04 Weighted Geometric Mean = 153.4
Internet Explorer (secondary app) AWadvs-04 Weighted Geometric Mean = 305.1
PhotoShop (secondary app) AWadvs-04 Weighted Geometric Mean = 298.6
Microsoft Word (secondary app) AWadvs-04 Weighted Geometric Mean = 305.2
From this, we concluded that if the second application was an OpenGL application, performance in the primary window would drop, likely, we theorized, because Nvidia was allocating OpenGL horsepower to the second window. On the other hand, if the application wasn't an OpenGL application, the performance drop was minimal, regardless of whether the application was an image editor, word processor, or browser.
This was a pretty exciting discovery, because it corresponded precisely with our view of the optimal approach. That is, if a user is running Pro/E on one monitor and checking e-mail with Internet Explorer on the other, we'd want all OpenGL resources allocated to Pro/E. On the other hand, if a user is running Lightwave in one window, and Lightwave Modeler in the other, we'd want the resources split to optimize performance in both windows. The question was, how will Nvidia's scheme play out in the SPECapc tests that we deemed the most reliable measure of performance?
Accordingly, we created our first two test scenarios; "Dual Monitor – OpenGL," where an OpenGL application like Lightwave, SolidWorks, or 3ds max was open in the second window, and "Dual Monitor – Non-OpenGL," where Internet Explorer was running on the second monitor.
Since some users might want to span one application over both monitors, a fairly common usage pattern for image and video editing, and certain other 2D development activities, we also attempted to create a test suite for this scenario, named Dual Monitor – Spanned. As we'll see, however, since most of our tests were designed for single monitor usage, and because spanned usage tended to bring out the worst in several boards, this test suite is the least complete.
Test Goals
Our main goals for dual-monitor testing were as follows: Which boards perform best under a variety of dual monitor scenarios for design and digital content creation (DCC) applications, and how should this impact your buying decision? An interesting undercurrent was whether Nvidia's resource allocation worked as well with SPECapc benchmarks as it appeared to with SPECviewperf tests.
How dual monitor usage impacted application and board stability. To accomplish this, we ran a number of discrete tests that we will discuss in sequence, holding our buying recommendations until the end, when we can consider all results. We'll conclude with an overall summary of single and dual monitor performance.
--------------------------------------
Intuitively, opening up a second monitor of equal resolution, color depth, and refresh rate doubles the load on the graphics card, which must now update twice as many pixels at each refresh. Of course, whether this produces an actual drop in performance depends on the percentage of board resources in use before opening the second monitor.
For example, with most dual monitor graphics cards, if you're reading your e-mail in Outlook and fire up your second monitor to check stock prices, you're not going to notice any degradation, since neither activity significantly strains the cards resources. On the other hand, if you're previewing a complicated animation in Lightwave, and then open up Modeler to work on some character design, you're likely to notice some sluggishness.
Entering this second phase of testing, our theory was that two basic elements would affect dual monitor performance-- hardware behavior and driver software. Specifically, if the graphics hardware was hardwired to allocate resources in a certain way once the second monitor was open, this could significantly impact OpenGL resource intensive projects open in the primary window. Second, we wondered whether the vendors could use their drivers to intelligently allocate resources according to the type of application open, as it appeared Nvidia was doing when we performed our early testing.
At a high level, we knew that both Nvidia and ATI shipped their products with dual monitor utilities, nView and HydraVision respectively, while 3Dlabs relied on the dual monitor capabilities in Windows 2000 and Windows XP. However, since dual monitor resource allocation strategies weren't covered in the spec sheets or readme files, we asked each vendor to describe what they were doing in this area.
3Dlabs was the most forthcoming from both a hardware and software perspective.
The Wildcat III has 2 rendering engines. When one display is used, both of the rendering engines are used. When dual displays are used, only one rendering engine per display is used. The backend processor is split....running slower with 2 displays too. Also, in single display mode, the Texture memory and Frame Buffer memory can each run at different speeds. In dual display mode, the Frame Buffer memory is 'limited' to the Texture memory speed, which is slower.
3Dlabs also stated that by using Windows to manage dual monitor usage, rather than designing their own program like the other vendors, they were forced to allocate OpenGL resources using the default Windows' scheme.
Nvidia disclosed that they had performed substantial work in this arena, but deemed this information proprietary, stating:
The allocation of resources for both single and dual displays is actually one of our secret sauces and hence we don't discuss the specifics.
Essentially the drivers are very well optimized to take advantage of all available graphics memory and constantly make decisions based on demands and load as to what is the best thing to do. We also optimize this feature even more on Quadro boards compared with GeForce boards to meet the demands of professional applications, which as you know tend to be very resource hungry.
--------------------------------------
Fair enough, but we would have liked a bit more.
Here's ATI's response.
As for our strategy for dual monitor heads, try not to think of it as two separate entities with separate resources allocated to each. Instead, think of the two monitors as one extended monitor running at a high resolution. Anytime you increase the resolution of a 3D window, you will run into a performance hit as both the CPU and the graphics card are doing increased amount of work. Additionally, you are increasing the amount of video memory you are using on the card with all of the buffering being done, thereby lowering the amount of local video memory you have available.
Again, good background information, but not a lot of meat to carry us through the testing phase and help us effectively analyze results.
Before discussing our tests, we should state that it was not our goal to test the breadth of functionality in any vendor's dual monitor utilities. Rather, they were strictly a means to an end, allowing us to achieve a consistent approach for each test scenario.
In our first two tests, with separate applications running in each window, we sought a configuration that would allow us to maximize each application in each window, which proved to be problematic. With the Wildcat, we simply moved the application to the respective window and maximized, which worked well.
ATI's dual monitor utility, HydraVision, also generally worked as advertised during setup and normal use, though it occasionally lost the preset for our monitors, forcing us to either set it manually or reboot until the driver found the proper preset. For our dual monitor scenario using separate application tests, we set the HydraVision Window control to "single monitor windows", also enabling "application position memory" as shown in Figure 1.
Nvidia's basic approach is to treat the desktop as one huge resource, rather than as separate monitors. Accordingly, in our dual monitor scenario with separate application tests, we disabled the "Enable window spanning across monitors" control as shown in Figure 2. For our dual monitor – span tests, we enabled this function.
In our dual monitor testing, we attempted to use the same pattern of tests as used in single monitor tests and fully described in our previous articles. Here's the basic order. First, we used Quantum3D's Real World Benchmark to calculate triangles per second and fill rate for each board. This gave us a baseline for theoretical performance. Next, we grabbed subtests from the Pro/E, 3ds max, and Unigraphics viewsets of the new SPECviewperf 7.0 test to compare performance in three critical tasks that factor significantly in all OpenGL development-- wireframe, shaded and facet shaded playback. As explained more fully in the first article, we used only these three new tests because vendors had been optimizing their drivers for the older tests for some time, which could skew performance. Then we looked at the actual SPECviewperf results, and finally, SPECapc and other application testing. Time considerations forced us to use a subset of the original test suite in our dual monitor testing.
----------------------------------------
In our Dual Monitor – OpenGL tests, we ran each test on the primary monitor, while running a second OpenGL application on the second monitor, with a model loaded, generally either SolidWorks, Lightwave, or 3ds max, but not actively processing a task, rendering, etc. Essentially it was loaded, but not actively executing work.
Theoretical Performance – Quantum 3D's Real World Benchmarks
Table 2, Theoretical Performance with Dual Monitor-OpenGL/Non-OpenGL modes
Wildcat Q4 900 Q4 750 FireGL Lightwave (OpenGL) open in second window
Score Delta Score Delta Score Delta Score Delta Triangles per second (millions of triangles per second) 4.03 0% 5.32 -55% 3.608 -69% 9.25 -2% Fill rate (mega pixels per second) 172.00 -58% 591.00 -9% 512 -12% 430.00 -6% Internet Explorer running in second Window Triangles per second 4.02 0% 11.59 -2% 11.697 -1% 9.27 -2% Fill rate 167.00 -59% 625.00 -4% 548 -6% 430.00 -6%
Table 2 shows the results of Real World tests running on the primary monitor measuring triangles per second and fill rate under two scenarios, the first with an OpenGL application (Lightwave) loaded on the second monitor, and the second with a non-OpenGL application (Internet Explorer) loaded on the second monitor. The first number is the raw score, the second (Delta) the percentage drop from single monitor scores (not shown).
As we can see, the Wildcat and FireGL don't seem to react differently to the type of application loaded. For the Wildcat, the 58% and 59% fill rate drops are likely the result of 3Dlabs allocating one of two raster engines to the second monitor once opened, cutting capacity to the first monitor significantly. Apparently, there were no similar allocations made with their chip's six T&L engines, since triangle performance was identical.
Note how the Nvidia cards respond differently by application type, dropping triangle performance significantly when a second OpenGL application is open, but hardly responding when Internet Explorer was open. This likely produced the effect we saw in our early testing, where the AWadvs-04 Geometric Mean dropped very little for Word, PhotoShop and Internet Explorer, but dropped by approximately 50% when two OpenGL applications, Lightwave and SolidWorks, were loaded.
The FireGL produced strong scores under both scenarios, but we wondered how this would affect performance on the application open on the second monitor. Specifically, it appeared that ATI was reserving all OpenGL horsepower for the primary monitor, with none for the second. While this should produce strong results for the application running on the primary monitor, it seemed to bode poorly for the application open on the second.
----------------------------------
These tests measure how well each board allocates their raw geometry and raster power to the basic building blocks of OpenGL applications-- wireframe, shaded, and facet shaded manipulation. Once again, these numbers were derived from the Pro/Engineer, Unigraphics and 3ds max viewsets of the new SPECviewperf 7 test suite. Here's what we found, showing both score and delta from single monitor performance.
Table 3, Primitives performance during Dual Monitor - OpenGL testing Running second OpenGL application Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta Wireframe Average (fps) 17.23 -27% 12.64 -14% 12.60 -14% 17.40 -3% Rank 2 3 4 1 Shaded Average (fps) 13.12 -2% 11.62 -5% -11.32 -5% 9.21 -1% Rank 1 2 3 4 Facet shaded Average (fps) 5.53 -2% 4.15 -1% 3.82 -1% 3.57 -0% Rank 1 2 3 4 Average Rank 1.3 2.33 3.33 3
FireGL's performance tracks its raw scores, which changed very little. This propelled FireGL to a first place finish in wireframe tests, but didn't help on the other two tests where single monitor performance was well behind all other boards. Nvidia's performance also tracked raw scores, with a drop in wireframe average tracking the reduction in triangles per second performance, while shaded and facet-shaded scores showed only minor decreases, mirroring the small decrease in raw fill rate performance.
In contrast, the Wildcat was a paradox. Given we saw no drop in Wildcat's raw triangles per second performance in the Quantum test, we can't explain the Wildcat's 27% drop in wireframe performance here, since wireframe tests are typically not limited by fill rate. In addition, we saw little performance change in shaded and faced shaded tests, which we are more fill rate intensive, where the Wildcat won both categories by significant margins. Definitely a trend to watch as we go forward.
Let's see how the primitives scores change with a non-OpenGL application.
Table 4, Primitives performance during Dual Monitor - NonOpenGL testing Running second OpenGL application Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta Wireframe Average (fps average only) 17.18 -27% 14.53 -1% 14.45 -1% 17.36 -3% Rank 2 3 4 1 Shaded Average (fps only) 12.91 -4% 12.12 -1% 11.69 -1% 9.21 -1% Rank 1 2 3 4 Facet shaded Average 5.50 -3% 4.17 -0% 3.84 -0% 3.57 -0% Rank 1 2 3 4 Average Rank 1.33 2.33 3.33 3.0
---------------------------------------
Results here for the Wildcat and FireGL are virtually identical to the results achieved with an OpenGL application open, which is what we would expect from the raw triangles per second and throughput scores, which also barely changed. That said, FireGL's results are consistent with its raw scores, while the Wildcat's, as pointed out in the previous section, are not.
You'll recall that the raw scores for both Quadro boards changed very little when Internet Explorer, a non-OpenGL application, was loaded in the second window. These scores in wire, shaded, and facet-shaded playback are entirely consistent, showing little degradation compared to the single monitor frame rates. At least for the primitives testing, Nvidia's OpenGL allocation scheme seemed to be working very well.
Wildcat comes out of both sets of primitives testing with a great overall ranking. The Quadro4 900 was second, with the FireGL third, better positioned than in single monitor testing, but solely due to its wireframe scores, since results in both shaded tests were poor. We'll see how this plays out in actual application testing.
Three tests influence our 3ds max buying decision-- the 3ds max component from the SPECviewperf, the SPECapc for 3ds max benchmark, and Discreet's own MaxBench test suite. We describe all tests in detail in the previous articles.
We treat 3ds max separately from other digital content creation (DCC) tests because it's the only DCC application for which graphics vendors can write a separate plug-in that replaces Discreet's own OpenGL functions. We saw in single monitor tests that both ATI's and Nvidia's plug-ins significantly boosted their respective product's performance compared to the Wildcat, which is great for prospective 3ds max users.
However, it's impossible to generalize these results to other DCC programs that don't offer the same plug-in architecture. For this reason, we'll consider general DCC performance separately down below.
Here we test board performance with Lightwave running on the second monitor.
Table 5, 3ds Max Performance in Dual Monitor - OpenGL testing Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPECviewperf 7 3ds Max 10.94 -6% 9.10 -0.48% 8.50 -1.80% 7.00 -1.30% Rank 1 2 3 4 3ds Max SPEC - Score 4.95 -22.78% 6.62 -2.07% 6.41 -0.93% 6.41 0.47% Rank 4 1 2 2 3ds Max Maxbench Score 24.77 -22.90% 41.56 -4.07% 39.61 -2.86% 20.51 -26.11% Rank 3 1 2 4 Average Rank 2.66 1.33 2.33 3.33
---------------------------------------
Table 5 illustrates once again why actual 3ds max application testing doesn't generalize. The SPECviewperf 7 3ds max component, which simulates 3ds max performance without running the actual application, shows the Wildcat in the lead, well ahead of the other boards, with only a narrow 6% performance drop from single monitor performance.
In the SPECapc, with applications and drivers engaged, the situation reverses completely, with Nvidia's Quadro4 900 edging out its sibling 750 and the FireGL, while trouncing the Wildcat by 25%. The Wildcat also does poorly on the MaxBench test, but we expected that, since it measures raw throughput more than real world performance, as we discussed in detail in our second segment. For example, MaxBench details show that the Wildcat drops 33-78% in texture related tests, and 74% in raster tests, entirely consistent with the 58% drop in fill rate shown in our raw tests.
Though the FireGL holds up well in the SPECapc test, it stumbles badly in MaxBench, with test detail showing drops of 51 and 54% in wireframe tests, and 46 and 53% in geometry tests, suggesting limitations in geometry performance not predicted by the raw or primitives tests.
Interestingly, neither Nvidia card showed the results of the 50+% drop in triangle performance or the 9+% drop in fill rate in the Maxbench tests. It looks like the GPU may have a back door to avoid this allocation scheme when the going gets tough on the primary monitor. Let's have a look at the results with Internet Explorer open in the second window.
Table 6, 3ds Max Performance in Dual Monitor - Non-OpenGL testing Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPECviewperf 7 3ds Max 10.92 -6.02% 9.11 -0.42% 8.60 -0.55% 6.99 -1.41% Rank 1 2 3 4 3ds Max SPEC - Score 4.91 -23.40% 6.47 -4.29% 6.42 -0.77% 6.17 -3.29% Rank 4 1 2 3 3ds Max Maxbench Score 24.80 -22.81% 41.64 -3.90% 39.61 -2.86% 20.61 -25.76% Rank 3 1 2 4 Average Rank 2.67 1.33 2.33 3.67
Once again, the Quadro4 900 dominates actual application testing, after losing to the Wildcat by a fairly substantial margin in the SPECviewperf 3ds max component. Given the relative raw performance scores between OpenGL and non-OpenGL second monitor usage, we expected to see some difference in Nvidia's scores, but we don't in the 3ds max category – there must really be something to that special sauce of theirs.
------------------------------------------
Based on what we know about the drop in Wildcat's raw fill rate with the second monitor open, and its drop in 3ds Max SPECapc performance, and to a much lesser degree, Maxbench, it's a tough sell among the 3ds Max crowd. For the FireGL, though neither the raw nor primitives scores would predict a drop in application performance, Maxbench seems to indicate that something is going on, while SPECviewperf results are well behind both other boards.
Let's see how the boards fare in general-purpose DCC programs.
Table 7, 8, and 9 show the results we would consider when choosing a board for general DCC use. The first, Table 7 shows performance results with an OpenGL application up in the second monitor, with a model loaded, but no activity.
Table 7, Dual Monitor - OpenGL testing - DCC applications Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPECviewperf 7 3ds Max 10.94 -5.85% 9.10 -0.48% 8.50 -1.80% 7.00 -1.30% SPEC VP 7 3ds Max - rank 1 2 3 4 Maya - fps 13.64 -49.63% 13.92 -36.90% 14.44 -34.00% 17.86 9.44% Maya - rank 4 2 3 1 DCC Average Rank 2.5 2 3 2.5
In the 3ds max SPECviewperf tests, the Wildcat continues to do well, but we see significant drops in Maya performance in shaded and textured modes, a trend that continued in later spanned tests. At some point, dropped raster capacity would have to impact performance, and this appeared to be the place.
Both Nvidia cards show significantly reduced performance for the Maya tests, the apparent result of the geometry horsepower we saw allocated to the second monitor in our raw tests.
Inexplicably, the FireGL performed better on Maya testing with two monitors open than with one, irrespective of the type of application open, propelling ATI's board to first place finished in both Maya tests. It also degraded very little on the Viewperf tests, making it appear to be a solid choice for serious dual monitor use.
At this point, the big question became whether the horsepower apparently "reserved" for the second monitor by the Wildcat and Nvidia cards would pay performance dividends in the application open in the second monitor. To answer this question, we look to Table 8, where we tested simultaneous, dual application performance.
Briefly, we ran dual application tests under two scenarios. In the first, Lightwave was the primary application and 3ds max was the secondary, and we ran the test twice, using two different models. In the second, Maya was the primary application, and Lightwave was the secondary, and we ran only one test.
---------------------------------------------
In all scenarios, we started the animation running in the primary application, and then in the secondary application, and measured the frame rate of both applications when running simultaneously. Then, we compared this frame rate to the frame rate achieved running in single monitor mode, computing the drop in performance attributable to simultaneous operation for both the primary and secondary application. We also ranked each board in both primary and secondary application. Table 8 shows the average results for all three tests.
Table 8, Dual application testing Overall Wildcat Q4 900 Q4 750 FireGL Avg. drop in primary app -78% -50% -51% -20% Avg. drop in secondary -44% -48% -52% -78% Rank - primary 4 2.33 2.67 1 Rank - secondary 2 1.33 2.67 4
To explain, in the primary application, the Wildcat averaged a drop in performance of 78% compared to single monitor scores, with an average drop of 44% in the secondary app. Not surprisingly given the average drop in performance, the Wildcat ranked last in the primary application, and second in the secondary application. This is reasonably consistent with what we know about 3Dlabs scheme of allocating one raster engine to both monitors, though the drop in the primary monitor was more severe than anticipated.
Interestingly, the Quadro4 produces the most balanced performance, with both primary and secondary applications dropping roughly equivalent levels, which is consistent with the drops in triangles per second performance seen in the raw scores. Whatever balancing act they're performing, it seems to work very well here.
It does appear that the FireGL is reserving most OpenGL horsepower for the primary application, with little resources allocated to the secondary monitor, scoring a perfect first place finish in the primary application and a perfect last in the secondary.
Drawing conclusions from this preliminary data is very difficult, since the test scenarios are very limited – after all, how many users care how well two animations play back simultaneously on two monitors. With no time for further testing, we're forced to wistfully ponder if we could manage to somehow run two SPECapc tests simultaneously on the separate monitors to produce more balanced, meaningful results.
Still, at the least, this data does tend steer you away from the FireGL if you care about the performance of the OpenGL application open in the secondary window. It also paints a negative picture of working with Wildcat with two OpenGL applications open, especially since the Wildcat came in last in the Dual Monitor – OpenGL testing for DCC shown in Table 7.
Let's see if the picture changes for Dual Monitor – Non-OpenGL testing.
----------------------------------------------
Here we ran the tests with Internet Explorer open on the second monitor.
Table 9, DCC testing with in Dual Monitor - Non-OpenGL testing Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPEC VP 7 3ds Max 10.92 -6.02% 9.11 -0.42% 8.60 -0.55% 6.99 -1.41% SPEC VP 7 3ds Max - rank 1 2 3 4 Maya - fps 17.03 -37.13% 18.75 -15.00% 18.10 -17.28% 22.48 37.71% Maya - rank 4 3 2 1 DCC Average Rank 2.5 2.5 2.5 2.5
In the SPECviewperf tests, the Wildcat dropped the most from single monitor performance, but still managed to win quite handily. This wasn't the case with Maya, where the Wildcat dropped the most, and came in last. Overall, though the Wildcat tied for first with all three other boards, it's tough to recommend the Wildcat for any kind of dual monitor DCC, especially after we discuss the problems experienced with Lightwave and Maya in spanned monitor use.
As we saw in the 3ds max dual monitor tests, both Quadro4 boards showed substantially less performance degradation with a non-OpenGL application open on the secondary monitor, which obviously is a very desired result. In DCC, at least, Nvidia's dual monitor allocation mechanism seems to work exceedingly well.
In Maya tests, FireGL continued to push more frames per second in dual monitor mode than in single monitor mode, a result that Mr. Spock would undoubtedly categorize as "illogical." Given its continued lackluster performance in the SPECviewperf test, it's impossible to know which result represents the reality one would experience in real world use.
Let's move on to design applications.
Design applications have long been the sweet spot for high-end OpenGL graphics cards, and remains somewhat of a last bastion, as Nvidia and now Radeon-based boards using games-oriented technology are capturing significant share in DCC. However, the design market, with less emphasis on texture and more on geometry, seems ideal for the agility and responsiveness shown by the Wildcat in negotiating around state changes and other OpenGL challenges. In contrast, especially with an OpenGL application open on the second monitor, triggering a 50%+ loss of triangle pushing power, high-end mechanical design seems like potential quicksand for the Nvidia based boards.
To assess our board's respective capabilities in this category, we focused on five tests, SPECapc application benchmarks for Pro/Engineer, SolidEdge, and SolidWorks, and two viewsets from the new SPECviewperf tests included Pro/Engineer and Unigraphics. Once again, we ignored the other design-oriented viewsets like Design Review, because we felt that all vendors had already optimized their drivers for these tests, risking results that would not reflect real world performance.
-----------------------------------------------
We should note up front that the Wildcat failed to run Pro/E in any dual monitor tests, as Pro/Engineer 2000i2, the version required for the SPECapc, would not run on the Wildcat with two monitors enabled, irrespective of the test parameters. 3Dlabs attributed this to a problem with Pro/E 2000i2, and considers this a legacy issue, since dual monitors worked well with Pro/Engineer 2002, the current version. We didn't have a copy of Pro/E 2002 on hand, but checked Pro/E developer PTC Corporation certifications list, and found the Wildcat certified on Dell, Compaq and HP Workstations, confirming 3Dlabs claims.
Table 10, Dual Monitor - OpenGL results for design applications Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPEC VP 7 - Pro/E 13.27 -5.42% 10.04 -1.86% 9.88 -1.64% 11.33 -3.74% SPEC VP7 - Pro/E 1 3 4 2 SPEC VP 7 - UGS Score 10.09 -18.63% 7.86 -32.28% 8.04 -26.70% 8.88 -2.47% SPEC Viewperf Ranking 1 2 3 4 Pro-E Rank - Score DNF DNF 4.93 -4.27% 4.92 -3.15% 4.43 -1.77% Pro-E Rank - DNF DNF 1 2 3 SolidEdge - Score 3.52 -2.93% 3.01 -6.99% 3.10 -4.24% 3.33 0.25% SolidEdge - Rank 1 4 3 2 SolidWorks - Score 3.02 -0.66% 2.64 -11.11% 2.65 -14.24% 2.71 -6.55% SolidWorks - Rank 1 4 3 2 MCAD Average Rank 1.00 2.8 3 2.60 Note: DNF stands for Did Not Function
Table 11, Dual Monitor - Non-OpenGL results for design applications Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPEC VP 7 - Pro/E 12.83 -8.55% 10.14 -0.88% 9.97 -0.70% 11.32 -3.82% SPEC VP7 - Pro/E rank 1 3 4 2 SPEC VP 7 - UGS 10.10 -18.55% 10.90 -6.03% 10.42 -5.01% 8.85 -2.71% SPECviewperf - UGS 3 1 2 4 Pro-E Rank - Score DNF DNF 4.96 -3.69% 4.86 -4.33% 4.44 -1.55% Pro-E Rank - DNF DNF 1 2 3 SolidEdge - Score 3.60 -0.72% 3.11 -6.38% 3.03 -3.66% 3.37 -6.36% SolidEdge - Rank 1 3 4 2 SolidWorks - Score 3.03 -0.66% 2.61 -12.12% 2.64 -14.56% 2.74 -5.52% SolidWorks - Rank 1 4 3 2 Average Rank - MCAD 1.50 2.4 3 2.60 Note: DNF stands for Did Not Function
-----------------------------------------------
Overall, regardless of the type of application open in the second window, Wildcat dominated, winning seven of the eight tests completed. More impressive was that Wildcat showed very little degradation in the SPECapc tests, losing a maximum of 3% of performance as compared to its single monitor scores. This is reasonably consistent with raw performance scores, since these tests are more geometry than fill rate intensive, but contradicts the significant drop in performance seen on the wireframe primitive tests.
FireGL was a surprising second place finisher, performing very well in the SolidWorks and SolidEdge benchmarks under both scenarios. This makes the picture much brighter for design than for DCC.
In four of these five design-oriented tests, both Nvidia boards showed little difference between OpenGL and non-OpenGL tests, breaking the pattern we saw throughout virtually all other testing. More importantly, though both boards performed well in Pro/E SPECapc tests, they trailed both the Wildcat and FireGL in SolidEdge and SolidWorks tests.
Both Nvidia boards lost much more ground to their single monitor results, especially with an OpenGL application open on the second monitor. Even with Internet Explorer open in the second window, however, neither Nvidia card recovered sufficiently to mount a serious challenge.
Let's move on to our final testing category, Dual Monitor – Spanned.
In these tests, we attempted to span the application across both monitors and then duplicate our single monitor tests. For this, we disabled nView for the Nvidia boards, and used Max button management for the FireGL as shown in Figure 3. With the Wildcat we simply stretched the application to the full double monitor surface.
Unfortunately, configuring the application across both monitors didn't work with the SolidEdge or SolidWorks SPECapc tests, which run from the command line and default to a single window. Ditto for both the old and new SPEC Viewperfs.
However, the Pro/E and both 3ds max tests ran fine across both monitors, except for graphics card-specific problems noted below. For our Lightwave and Maya ad hoc tests, we centered the display so that it precisely corresponded with the break in the two monitors, and then ran our animation playback test suites.
Table 12, Dual Monitor - Spanned tests Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPECapc 3ds Max 3.91 -39% 7.24 7.10% 6.97 7.73% DNF Rank 3 1 2 3ds Max Maxbench 17.00 -22.90% 39.07 -4.07% 37.00 -2.86% 22.93 -26.11% Rank 4 1 2 3 SPECapc - Pro/E Score DNF 4.91 -4.66% 4.89 -3.74% 4.03 -10.64% Rank 1 2 3 Lightwave - fps 12.66 -10.33% 12.91 -3.20% 12.91 -5.03% 13.10 -2.72% Rank 4 3 2 1 Maya - fps DNF 11.56 -47.60% 11.14 -49.09% 12.36 -24.26% Rank 3 2 1
-------------------------------------------------
One of the first anomalies we noted was the FireGL's 2048x2048 3D rendering limitation. We saw this immediately when we tried to span across our two 1280x1024 desktops, and had 3ds max and Lightwave snapping back to about 60% of the second monitor. We pinged our ATI support contact and got the following reply.
The FireGL 8800 has a 3D rendering limitation of 2048x2048. The resolution you are running with 2x1280x1024 is 2560x1024 which exceeds the 3D rendering limit, so we will force the window smaller to stay within this limitation.
As we discussed in part 1, ATI says that few of their customers encounter this problem, because most tend to run different applications in the separate monitors. Probably true enough, but this is a concern for users who need complete dual monitor real estate, and a serious competitive disadvantage versus the other products, which spanned just fine.
Our contact posited that this limit also caused the FireGL to DNF in the 3ds max SPECapc, though the route was circuitous. Specifically, the test aborted just after liftoff, reporting that the board didn't support the required minimum of 8 lights in the viewport. To this question, our contact replied:
I suspect the test is trying to force full screen which would exceed the resolution limitation and is encountering results that it cannot deal with and is interpreting this as a lighting limitation of the card.
Whatever the cause, this problem did not prevent us from running the Maxbench test, indicating that the FireGL works well with 3ds max up to the 2048 limit; it simply can't run the 3ds max SPECapc benchmark spanned across both screens fully.
In other 3ds max SPECapc tests, we noticed immediately that the two Nvidia cards were actually faster in span mode than on single monitor tests. Our immediate response was to retest in single monitor mode, which verified our initial results.
Then, we watched carefully throughout the automated SPECapc test, and saw that 3ds max was zooming in on all animations to support the much wider aspect ratio, cutting off a significant portion of the animation playing on screen. This was particularly apparent with the juggler sequence, shown in Figure 4.
What's interesting is how the Nvidia boards reacted to this reduced animation compared to the Wildcat. Both Nvidia cards played the juggler sequences about 8 seconds faster than when tested on a single monitor, reducing a 20 second playback time down to 12 seconds in all juggler related tests. This makes sense, given that less animation is actually displayed on screen, which means less work.
In contrast, however, the Wildcat's playback time for this same sequence increased from 21 seconds to 72 seconds, accounting for much of the 133 seconds added when going from solo to span mode. This is yet another area where Nvidia's custom 3ds max driver showed a remarkable ability to boost performance under unusual conditions, though a smaller effective window was displayed, where 3Dlabs' driver did just the reverse.
-----------------------------------------------
Remember to discount the FireGL's narrow victory in the Lightwave and Maya tests by the 2048x2048 rendering limitation, which means it pushed fewer pixels than the other cards. In addition, we should note two problems experienced with the Wildcat in these tests. The first occurred in Lightwave, where the board failed to display the animation timeline on the second monitor, truncating the display at the end of the first monitor. Playback controls displayed normally, however, so you could play and stop the animation, you just couldn't see the second part of the timeline.
Second was more serious, the inability to run Maya fully spanned across two monitors. The Wildcat had no problem displaying 3ds max and Lightwave across two monitors, and Maya spanned to the full 2560x1024 on the two Nvidia cards, and up to the FireGL's 2048x1024 rendering limit. However, with the Wildcat, Maya kept snapping back to 1280x1024 resolution whenever we attempted to stretch the application. We asked 3Dlabs about this issue and they confirmed the problem, but had no solution.
The FireGL also experienced problems with the Pro/E test, spewing massive amounts of screen garbage in any window that spanned more than one monitor, while any window contained in a single monitor displayed normally (See Figure 5). ATI attributed these problems to the aforementioned 2048 rendering limitation, stating that any screen that strayed beyond these boundaries would become corrupted. Either way, Pro/E developers seeking to span dual monitors should probably select another board.
Overall, the lack of consistent, across the board results makes ranking in this category somewhat less important than the stability issues raised. Nvidia has long suffered from an impression that their drivers were not as advanced as their graphics chips, but the lack of a DNF for either board in this category speaks volumes about how far they've come, notwithstanding some of the higher level issues we experienced with nView.
Let's move on and see where all this data takes us.
Table 13, Summary of Results Wildcat Quadro 4 900 Quadro 4 750 FireGL 8800 Single Monitor SPECapc for 3ds Max 3 1 2 4 Other DCC 1.00 2.67 2.67 3.67 Design 1.20 2.60 3 3 AutoCAD 4 1 2 3 Dual Monitor 3ds Max - OpenGL 2.67 1.33 2.33 3.33 3ds Max - Non-OpenGL 2.67 1.33 2.33 3.67 Other DCC - OpenGL 2.5 2 3 2.5 Other DCC - Non-OpenGL 2.5 2.5 2.5 2.5 Design - OpenGL 1 2.8 3 2.6 Design - Non-OpenGL 1.5 2.4 3 2.6
--------------------------------------
3Dlabs Wildcat III 6110
The Wildcat III 6110 won all design oriented category rankings, both single and dual monitor, often by significant margins, making it the board of choice for those who value performance over price. In most DCC-oriented tests, however, performance waned, especially in dual monitor tests.
We wouldn't throw the Wildcat III permanently out of contention for DCC, however, because it's obvious that their 3ds max plug-in left a lot of performance on the table compared to Nvidia. 3Dlabs made some serious noises about upgrading their plug-in during our conversations; it will be interesting to see if they take this step and how much performance they will gain from it.
3Dlabs doesn't offer dual monitor utilities, which we didn't miss at all during our tests, preferring to use the basic Windows controls over either Nvidia's or ATI's utilities. While generally very stable, the Wildcat couldn't span Maya greater than a single screen width, and also had problems with a disappearing animation slider when spanning Lightwave across multiple monitors.
Nvidia Quadro 4 750 and 900
Both Nvidia boards emerged as digital content creation champs, though behind the Wildcat for more traditional design. The performance difference between the 750 and 900 was generally pretty minimal; unless you absolutely need dual digital monitor output, you'll find the 750 delivers greater bang for the buck.
We liked Nvidia's generally efficient drivers, though certain design decisions, like defaulting to Vertical Synch on, drove us crazy during our tests. Still, both boards finished all tests, without the screen anomalies experienced by the FireGL or the application incompatibilities suffered by 3Dlabs.
Nvidia also appears to have given the most thought to dual monitor operation. We saw this in many areas, most notably the almost 50/50 performance allocation between foreground and background applications in our dual monitor simultaneous application tests.
ATI FireGL 8800
The FireGL showed occasional flashes of brilliance, particularly in dual monitor design oriented tasks, but price, rather than performance, is clearly its most attractive option. The FireGL was the only board with a rendering limitation (2048x2048) that prevented it from supporting two complete dual windows, a factor those planning on spanning their applications over dual monitors need to consider.
We liked ATI's HydraVision dual monitor utilities; though we found them a bit peripatetic with too many different tabs and windows. Operation was generally stable, except for the occasional need to reboot so the utilities could properly identify one or both of our test bed monitors (allowing us to set the appropriate refresh rate).
That ends our three part series on OpenGL cards. We realize we presented an enormous amount of data, and we hope you have a better understanding of the relative merits of the tested cards.
Copyright © 2002 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in ExtremeTech.
That work done, in this review, we shift our attention to how each card performs while driving two monitors. As we'll see, this involves both hardware and software decisions regarding how a board allocates its collective OpenGL horsepower between two open monitors. We'll also see a dramatic range in performance degradation when dual monitors are running on our respective boards.
Speaking of boards, let's get reacquainted with the boards in this review, which includes the 3Dlabs Wildcat III 6110 ($1,500 - $2,000 street), ATI's FireGL 8800 ($599 street), Nvidia's Quadro4 900 ($1,500 street) and Nvidia's Quadro4 750 ($995 street). We included an extensive features table in the first segment. Note that we used the same driver revisions as in the first two story segments for consistency, and we indicate those versions in the first segment. There may be newer drivers released in the past month.
Table 1, Dual Monitor Support All Segments Combined All Segments Combined EDA DCC FINANCE GIS/Geo One 82% 82% 70% 88% 85% 81% Two 17% 16% 30% 10% 15% 19% Three 1% 2% 0% 0% 0% 0% Four 1% 0% 0% 3% 0% 0% Source: IDC, 2001
Dual monitor support started appearing on OpenGL graphics cards several product generations ago, but actual dual monitor use is still fairly modest, at least in 2001, when IDC performed the study shown in Table 1. That said, recent price breaks on LCD monitors, and ever faster computers and graphics cards, makes dual monitor use much more attractive today than in the past. All three graphics card vendors felt that dual monitor use would increase appreciably over the next few years.
With dual monitor use modest but growing, it appeared that benchmarking performance under dual monitor use was, or would soon be, important for those making buying decisions. The question was, how to test?
Note that the IDC study didn't describe how users were actually configuring their applications over the dual monitors. Specifically, we don't know what percentage of usage was spanning one application over both monitors, and which scenarios used each monitor for a different application. SPEC tests, all devised for single monitor application, and very well defined for that type of tests, provided little help except when used in concert with other applications.
After some early experimentation, we arrived at three scenarios that likely represent a significant percentage of actual dual monitor use. The first two assumed that different applications are being run in the primary and secondary monitor. We assumed that an engineer running Pro/Engineer in one monitor might run Internet Explorer in the other, or perhaps a second OpenGL program to assist their development efforts. To test performance under this scenario, we enabled the second monitor, opened up the second application, and ran the benchmark test in the primary monitor. Obviously, choosing which application(s) would be open in the second monitor was a key test criteria.
An important point to make here is that for most of our dual monitor testing we weren't attempting to run intensive workloads on both monitors simultaneously, though we did have one section of testing with dual, simultaneous workloads measured. Most of our testing involved loading different types of applications for display on the second monitor, with a model loaded to engage the card's OpenGL facilities when appropriate, but without initiating active workloads.
When running an OpenGL application on the second monitor, it simulates a designer creating a model in one application, then loading it in another. When a non-OpenGL application was loaded, it simulates an e-mail or word processor open in the second window, with an active design in the primary window. .
Before selecting which programs would be open in the second monitor, we experimented with a variety of applications, including Internet Explorer, Microsoft Word and PhotoShop, finding that the boards generally responded in one of two ways (at least in our tests with components of the SPECviewperf 6.1.2 suite run on the primary monitor).
First, the Wildcat and the FireGL boards seemed to react similarly irrespective of the type of application, reacting more to the presence of a second open monitor than the type of application. In contrast, the two Nvidia cards reacted very differently depending upon the type of application running in the second window. Here are some of our results.
---------------------------------------
Single monitor AWadvs-04 Weighted Geometric Mean = 304.2
Lightwave (secondary app) AWadvs-04 Weighted Geometric Mean = 156.8
SolidWorks (secondary app) AWadvs-04 Weighted Geometric Mean = 153.4
Internet Explorer (secondary app) AWadvs-04 Weighted Geometric Mean = 305.1
PhotoShop (secondary app) AWadvs-04 Weighted Geometric Mean = 298.6
Microsoft Word (secondary app) AWadvs-04 Weighted Geometric Mean = 305.2
From this, we concluded that if the second application was an OpenGL application, performance in the primary window would drop, likely, we theorized, because Nvidia was allocating OpenGL horsepower to the second window. On the other hand, if the application wasn't an OpenGL application, the performance drop was minimal, regardless of whether the application was an image editor, word processor, or browser.
This was a pretty exciting discovery, because it corresponded precisely with our view of the optimal approach. That is, if a user is running Pro/E on one monitor and checking e-mail with Internet Explorer on the other, we'd want all OpenGL resources allocated to Pro/E. On the other hand, if a user is running Lightwave in one window, and Lightwave Modeler in the other, we'd want the resources split to optimize performance in both windows. The question was, how will Nvidia's scheme play out in the SPECapc tests that we deemed the most reliable measure of performance?
Accordingly, we created our first two test scenarios; "Dual Monitor – OpenGL," where an OpenGL application like Lightwave, SolidWorks, or 3ds max was open in the second window, and "Dual Monitor – Non-OpenGL," where Internet Explorer was running on the second monitor.
Since some users might want to span one application over both monitors, a fairly common usage pattern for image and video editing, and certain other 2D development activities, we also attempted to create a test suite for this scenario, named Dual Monitor – Spanned. As we'll see, however, since most of our tests were designed for single monitor usage, and because spanned usage tended to bring out the worst in several boards, this test suite is the least complete.
Test Goals
Our main goals for dual-monitor testing were as follows: Which boards perform best under a variety of dual monitor scenarios for design and digital content creation (DCC) applications, and how should this impact your buying decision? An interesting undercurrent was whether Nvidia's resource allocation worked as well with SPECapc benchmarks as it appeared to with SPECviewperf tests.
How dual monitor usage impacted application and board stability. To accomplish this, we ran a number of discrete tests that we will discuss in sequence, holding our buying recommendations until the end, when we can consider all results. We'll conclude with an overall summary of single and dual monitor performance.
--------------------------------------
Intuitively, opening up a second monitor of equal resolution, color depth, and refresh rate doubles the load on the graphics card, which must now update twice as many pixels at each refresh. Of course, whether this produces an actual drop in performance depends on the percentage of board resources in use before opening the second monitor.
For example, with most dual monitor graphics cards, if you're reading your e-mail in Outlook and fire up your second monitor to check stock prices, you're not going to notice any degradation, since neither activity significantly strains the cards resources. On the other hand, if you're previewing a complicated animation in Lightwave, and then open up Modeler to work on some character design, you're likely to notice some sluggishness.
Entering this second phase of testing, our theory was that two basic elements would affect dual monitor performance-- hardware behavior and driver software. Specifically, if the graphics hardware was hardwired to allocate resources in a certain way once the second monitor was open, this could significantly impact OpenGL resource intensive projects open in the primary window. Second, we wondered whether the vendors could use their drivers to intelligently allocate resources according to the type of application open, as it appeared Nvidia was doing when we performed our early testing.
At a high level, we knew that both Nvidia and ATI shipped their products with dual monitor utilities, nView and HydraVision respectively, while 3Dlabs relied on the dual monitor capabilities in Windows 2000 and Windows XP. However, since dual monitor resource allocation strategies weren't covered in the spec sheets or readme files, we asked each vendor to describe what they were doing in this area.
3Dlabs was the most forthcoming from both a hardware and software perspective.
The Wildcat III has 2 rendering engines. When one display is used, both of the rendering engines are used. When dual displays are used, only one rendering engine per display is used. The backend processor is split....running slower with 2 displays too. Also, in single display mode, the Texture memory and Frame Buffer memory can each run at different speeds. In dual display mode, the Frame Buffer memory is 'limited' to the Texture memory speed, which is slower.
3Dlabs also stated that by using Windows to manage dual monitor usage, rather than designing their own program like the other vendors, they were forced to allocate OpenGL resources using the default Windows' scheme.
Nvidia disclosed that they had performed substantial work in this arena, but deemed this information proprietary, stating:
The allocation of resources for both single and dual displays is actually one of our secret sauces and hence we don't discuss the specifics.
Essentially the drivers are very well optimized to take advantage of all available graphics memory and constantly make decisions based on demands and load as to what is the best thing to do. We also optimize this feature even more on Quadro boards compared with GeForce boards to meet the demands of professional applications, which as you know tend to be very resource hungry.
--------------------------------------
Fair enough, but we would have liked a bit more.
Here's ATI's response.
As for our strategy for dual monitor heads, try not to think of it as two separate entities with separate resources allocated to each. Instead, think of the two monitors as one extended monitor running at a high resolution. Anytime you increase the resolution of a 3D window, you will run into a performance hit as both the CPU and the graphics card are doing increased amount of work. Additionally, you are increasing the amount of video memory you are using on the card with all of the buffering being done, thereby lowering the amount of local video memory you have available.
Again, good background information, but not a lot of meat to carry us through the testing phase and help us effectively analyze results.
Before discussing our tests, we should state that it was not our goal to test the breadth of functionality in any vendor's dual monitor utilities. Rather, they were strictly a means to an end, allowing us to achieve a consistent approach for each test scenario.
In our first two tests, with separate applications running in each window, we sought a configuration that would allow us to maximize each application in each window, which proved to be problematic. With the Wildcat, we simply moved the application to the respective window and maximized, which worked well.
ATI's dual monitor utility, HydraVision, also generally worked as advertised during setup and normal use, though it occasionally lost the preset for our monitors, forcing us to either set it manually or reboot until the driver found the proper preset. For our dual monitor scenario using separate application tests, we set the HydraVision Window control to "single monitor windows", also enabling "application position memory" as shown in Figure 1.
Nvidia's basic approach is to treat the desktop as one huge resource, rather than as separate monitors. Accordingly, in our dual monitor scenario with separate application tests, we disabled the "Enable window spanning across monitors" control as shown in Figure 2. For our dual monitor – span tests, we enabled this function.
In our dual monitor testing, we attempted to use the same pattern of tests as used in single monitor tests and fully described in our previous articles. Here's the basic order. First, we used Quantum3D's Real World Benchmark to calculate triangles per second and fill rate for each board. This gave us a baseline for theoretical performance. Next, we grabbed subtests from the Pro/E, 3ds max, and Unigraphics viewsets of the new SPECviewperf 7.0 test to compare performance in three critical tasks that factor significantly in all OpenGL development-- wireframe, shaded and facet shaded playback. As explained more fully in the first article, we used only these three new tests because vendors had been optimizing their drivers for the older tests for some time, which could skew performance. Then we looked at the actual SPECviewperf results, and finally, SPECapc and other application testing. Time considerations forced us to use a subset of the original test suite in our dual monitor testing.
----------------------------------------
In our Dual Monitor – OpenGL tests, we ran each test on the primary monitor, while running a second OpenGL application on the second monitor, with a model loaded, generally either SolidWorks, Lightwave, or 3ds max, but not actively processing a task, rendering, etc. Essentially it was loaded, but not actively executing work.
Theoretical Performance – Quantum 3D's Real World Benchmarks
Table 2, Theoretical Performance with Dual Monitor-OpenGL/Non-OpenGL modes
Wildcat Q4 900 Q4 750 FireGL Lightwave (OpenGL) open in second window
Score Delta Score Delta Score Delta Score Delta Triangles per second (millions of triangles per second) 4.03 0% 5.32 -55% 3.608 -69% 9.25 -2% Fill rate (mega pixels per second) 172.00 -58% 591.00 -9% 512 -12% 430.00 -6% Internet Explorer running in second Window Triangles per second 4.02 0% 11.59 -2% 11.697 -1% 9.27 -2% Fill rate 167.00 -59% 625.00 -4% 548 -6% 430.00 -6%
Table 2 shows the results of Real World tests running on the primary monitor measuring triangles per second and fill rate under two scenarios, the first with an OpenGL application (Lightwave) loaded on the second monitor, and the second with a non-OpenGL application (Internet Explorer) loaded on the second monitor. The first number is the raw score, the second (Delta) the percentage drop from single monitor scores (not shown).
As we can see, the Wildcat and FireGL don't seem to react differently to the type of application loaded. For the Wildcat, the 58% and 59% fill rate drops are likely the result of 3Dlabs allocating one of two raster engines to the second monitor once opened, cutting capacity to the first monitor significantly. Apparently, there were no similar allocations made with their chip's six T&L engines, since triangle performance was identical.
Note how the Nvidia cards respond differently by application type, dropping triangle performance significantly when a second OpenGL application is open, but hardly responding when Internet Explorer was open. This likely produced the effect we saw in our early testing, where the AWadvs-04 Geometric Mean dropped very little for Word, PhotoShop and Internet Explorer, but dropped by approximately 50% when two OpenGL applications, Lightwave and SolidWorks, were loaded.
The FireGL produced strong scores under both scenarios, but we wondered how this would affect performance on the application open on the second monitor. Specifically, it appeared that ATI was reserving all OpenGL horsepower for the primary monitor, with none for the second. While this should produce strong results for the application running on the primary monitor, it seemed to bode poorly for the application open on the second.
----------------------------------
These tests measure how well each board allocates their raw geometry and raster power to the basic building blocks of OpenGL applications-- wireframe, shaded, and facet shaded manipulation. Once again, these numbers were derived from the Pro/Engineer, Unigraphics and 3ds max viewsets of the new SPECviewperf 7 test suite. Here's what we found, showing both score and delta from single monitor performance.
Table 3, Primitives performance during Dual Monitor - OpenGL testing Running second OpenGL application Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta Wireframe Average (fps) 17.23 -27% 12.64 -14% 12.60 -14% 17.40 -3% Rank 2 3 4 1 Shaded Average (fps) 13.12 -2% 11.62 -5% -11.32 -5% 9.21 -1% Rank 1 2 3 4 Facet shaded Average (fps) 5.53 -2% 4.15 -1% 3.82 -1% 3.57 -0% Rank 1 2 3 4 Average Rank 1.3 2.33 3.33 3
FireGL's performance tracks its raw scores, which changed very little. This propelled FireGL to a first place finish in wireframe tests, but didn't help on the other two tests where single monitor performance was well behind all other boards. Nvidia's performance also tracked raw scores, with a drop in wireframe average tracking the reduction in triangles per second performance, while shaded and facet-shaded scores showed only minor decreases, mirroring the small decrease in raw fill rate performance.
In contrast, the Wildcat was a paradox. Given we saw no drop in Wildcat's raw triangles per second performance in the Quantum test, we can't explain the Wildcat's 27% drop in wireframe performance here, since wireframe tests are typically not limited by fill rate. In addition, we saw little performance change in shaded and faced shaded tests, which we are more fill rate intensive, where the Wildcat won both categories by significant margins. Definitely a trend to watch as we go forward.
Let's see how the primitives scores change with a non-OpenGL application.
Table 4, Primitives performance during Dual Monitor - NonOpenGL testing Running second OpenGL application Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta Wireframe Average (fps average only) 17.18 -27% 14.53 -1% 14.45 -1% 17.36 -3% Rank 2 3 4 1 Shaded Average (fps only) 12.91 -4% 12.12 -1% 11.69 -1% 9.21 -1% Rank 1 2 3 4 Facet shaded Average 5.50 -3% 4.17 -0% 3.84 -0% 3.57 -0% Rank 1 2 3 4 Average Rank 1.33 2.33 3.33 3.0
---------------------------------------
Results here for the Wildcat and FireGL are virtually identical to the results achieved with an OpenGL application open, which is what we would expect from the raw triangles per second and throughput scores, which also barely changed. That said, FireGL's results are consistent with its raw scores, while the Wildcat's, as pointed out in the previous section, are not.
You'll recall that the raw scores for both Quadro boards changed very little when Internet Explorer, a non-OpenGL application, was loaded in the second window. These scores in wire, shaded, and facet-shaded playback are entirely consistent, showing little degradation compared to the single monitor frame rates. At least for the primitives testing, Nvidia's OpenGL allocation scheme seemed to be working very well.
Wildcat comes out of both sets of primitives testing with a great overall ranking. The Quadro4 900 was second, with the FireGL third, better positioned than in single monitor testing, but solely due to its wireframe scores, since results in both shaded tests were poor. We'll see how this plays out in actual application testing.
Three tests influence our 3ds max buying decision-- the 3ds max component from the SPECviewperf, the SPECapc for 3ds max benchmark, and Discreet's own MaxBench test suite. We describe all tests in detail in the previous articles.
We treat 3ds max separately from other digital content creation (DCC) tests because it's the only DCC application for which graphics vendors can write a separate plug-in that replaces Discreet's own OpenGL functions. We saw in single monitor tests that both ATI's and Nvidia's plug-ins significantly boosted their respective product's performance compared to the Wildcat, which is great for prospective 3ds max users.
However, it's impossible to generalize these results to other DCC programs that don't offer the same plug-in architecture. For this reason, we'll consider general DCC performance separately down below.
Here we test board performance with Lightwave running on the second monitor.
Table 5, 3ds Max Performance in Dual Monitor - OpenGL testing Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPECviewperf 7 3ds Max 10.94 -6% 9.10 -0.48% 8.50 -1.80% 7.00 -1.30% Rank 1 2 3 4 3ds Max SPEC - Score 4.95 -22.78% 6.62 -2.07% 6.41 -0.93% 6.41 0.47% Rank 4 1 2 2 3ds Max Maxbench Score 24.77 -22.90% 41.56 -4.07% 39.61 -2.86% 20.51 -26.11% Rank 3 1 2 4 Average Rank 2.66 1.33 2.33 3.33
---------------------------------------
Table 5 illustrates once again why actual 3ds max application testing doesn't generalize. The SPECviewperf 7 3ds max component, which simulates 3ds max performance without running the actual application, shows the Wildcat in the lead, well ahead of the other boards, with only a narrow 6% performance drop from single monitor performance.
In the SPECapc, with applications and drivers engaged, the situation reverses completely, with Nvidia's Quadro4 900 edging out its sibling 750 and the FireGL, while trouncing the Wildcat by 25%. The Wildcat also does poorly on the MaxBench test, but we expected that, since it measures raw throughput more than real world performance, as we discussed in detail in our second segment. For example, MaxBench details show that the Wildcat drops 33-78% in texture related tests, and 74% in raster tests, entirely consistent with the 58% drop in fill rate shown in our raw tests.
Though the FireGL holds up well in the SPECapc test, it stumbles badly in MaxBench, with test detail showing drops of 51 and 54% in wireframe tests, and 46 and 53% in geometry tests, suggesting limitations in geometry performance not predicted by the raw or primitives tests.
Interestingly, neither Nvidia card showed the results of the 50+% drop in triangle performance or the 9+% drop in fill rate in the Maxbench tests. It looks like the GPU may have a back door to avoid this allocation scheme when the going gets tough on the primary monitor. Let's have a look at the results with Internet Explorer open in the second window.
Table 6, 3ds Max Performance in Dual Monitor - Non-OpenGL testing Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPECviewperf 7 3ds Max 10.92 -6.02% 9.11 -0.42% 8.60 -0.55% 6.99 -1.41% Rank 1 2 3 4 3ds Max SPEC - Score 4.91 -23.40% 6.47 -4.29% 6.42 -0.77% 6.17 -3.29% Rank 4 1 2 3 3ds Max Maxbench Score 24.80 -22.81% 41.64 -3.90% 39.61 -2.86% 20.61 -25.76% Rank 3 1 2 4 Average Rank 2.67 1.33 2.33 3.67
Once again, the Quadro4 900 dominates actual application testing, after losing to the Wildcat by a fairly substantial margin in the SPECviewperf 3ds max component. Given the relative raw performance scores between OpenGL and non-OpenGL second monitor usage, we expected to see some difference in Nvidia's scores, but we don't in the 3ds max category – there must really be something to that special sauce of theirs.
------------------------------------------
Based on what we know about the drop in Wildcat's raw fill rate with the second monitor open, and its drop in 3ds Max SPECapc performance, and to a much lesser degree, Maxbench, it's a tough sell among the 3ds Max crowd. For the FireGL, though neither the raw nor primitives scores would predict a drop in application performance, Maxbench seems to indicate that something is going on, while SPECviewperf results are well behind both other boards.
Let's see how the boards fare in general-purpose DCC programs.
Table 7, 8, and 9 show the results we would consider when choosing a board for general DCC use. The first, Table 7 shows performance results with an OpenGL application up in the second monitor, with a model loaded, but no activity.
Table 7, Dual Monitor - OpenGL testing - DCC applications Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPECviewperf 7 3ds Max 10.94 -5.85% 9.10 -0.48% 8.50 -1.80% 7.00 -1.30% SPEC VP 7 3ds Max - rank 1 2 3 4 Maya - fps 13.64 -49.63% 13.92 -36.90% 14.44 -34.00% 17.86 9.44% Maya - rank 4 2 3 1 DCC Average Rank 2.5 2 3 2.5
In the 3ds max SPECviewperf tests, the Wildcat continues to do well, but we see significant drops in Maya performance in shaded and textured modes, a trend that continued in later spanned tests. At some point, dropped raster capacity would have to impact performance, and this appeared to be the place.
Both Nvidia cards show significantly reduced performance for the Maya tests, the apparent result of the geometry horsepower we saw allocated to the second monitor in our raw tests.
Inexplicably, the FireGL performed better on Maya testing with two monitors open than with one, irrespective of the type of application open, propelling ATI's board to first place finished in both Maya tests. It also degraded very little on the Viewperf tests, making it appear to be a solid choice for serious dual monitor use.
At this point, the big question became whether the horsepower apparently "reserved" for the second monitor by the Wildcat and Nvidia cards would pay performance dividends in the application open in the second monitor. To answer this question, we look to Table 8, where we tested simultaneous, dual application performance.
Briefly, we ran dual application tests under two scenarios. In the first, Lightwave was the primary application and 3ds max was the secondary, and we ran the test twice, using two different models. In the second, Maya was the primary application, and Lightwave was the secondary, and we ran only one test.
---------------------------------------------
In all scenarios, we started the animation running in the primary application, and then in the secondary application, and measured the frame rate of both applications when running simultaneously. Then, we compared this frame rate to the frame rate achieved running in single monitor mode, computing the drop in performance attributable to simultaneous operation for both the primary and secondary application. We also ranked each board in both primary and secondary application. Table 8 shows the average results for all three tests.
Table 8, Dual application testing Overall Wildcat Q4 900 Q4 750 FireGL Avg. drop in primary app -78% -50% -51% -20% Avg. drop in secondary -44% -48% -52% -78% Rank - primary 4 2.33 2.67 1 Rank - secondary 2 1.33 2.67 4
To explain, in the primary application, the Wildcat averaged a drop in performance of 78% compared to single monitor scores, with an average drop of 44% in the secondary app. Not surprisingly given the average drop in performance, the Wildcat ranked last in the primary application, and second in the secondary application. This is reasonably consistent with what we know about 3Dlabs scheme of allocating one raster engine to both monitors, though the drop in the primary monitor was more severe than anticipated.
Interestingly, the Quadro4 produces the most balanced performance, with both primary and secondary applications dropping roughly equivalent levels, which is consistent with the drops in triangles per second performance seen in the raw scores. Whatever balancing act they're performing, it seems to work very well here.
It does appear that the FireGL is reserving most OpenGL horsepower for the primary application, with little resources allocated to the secondary monitor, scoring a perfect first place finish in the primary application and a perfect last in the secondary.
Drawing conclusions from this preliminary data is very difficult, since the test scenarios are very limited – after all, how many users care how well two animations play back simultaneously on two monitors. With no time for further testing, we're forced to wistfully ponder if we could manage to somehow run two SPECapc tests simultaneously on the separate monitors to produce more balanced, meaningful results.
Still, at the least, this data does tend steer you away from the FireGL if you care about the performance of the OpenGL application open in the secondary window. It also paints a negative picture of working with Wildcat with two OpenGL applications open, especially since the Wildcat came in last in the Dual Monitor – OpenGL testing for DCC shown in Table 7.
Let's see if the picture changes for Dual Monitor – Non-OpenGL testing.
----------------------------------------------
Here we ran the tests with Internet Explorer open on the second monitor.
Table 9, DCC testing with in Dual Monitor - Non-OpenGL testing Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPEC VP 7 3ds Max 10.92 -6.02% 9.11 -0.42% 8.60 -0.55% 6.99 -1.41% SPEC VP 7 3ds Max - rank 1 2 3 4 Maya - fps 17.03 -37.13% 18.75 -15.00% 18.10 -17.28% 22.48 37.71% Maya - rank 4 3 2 1 DCC Average Rank 2.5 2.5 2.5 2.5
In the SPECviewperf tests, the Wildcat dropped the most from single monitor performance, but still managed to win quite handily. This wasn't the case with Maya, where the Wildcat dropped the most, and came in last. Overall, though the Wildcat tied for first with all three other boards, it's tough to recommend the Wildcat for any kind of dual monitor DCC, especially after we discuss the problems experienced with Lightwave and Maya in spanned monitor use.
As we saw in the 3ds max dual monitor tests, both Quadro4 boards showed substantially less performance degradation with a non-OpenGL application open on the secondary monitor, which obviously is a very desired result. In DCC, at least, Nvidia's dual monitor allocation mechanism seems to work exceedingly well.
In Maya tests, FireGL continued to push more frames per second in dual monitor mode than in single monitor mode, a result that Mr. Spock would undoubtedly categorize as "illogical." Given its continued lackluster performance in the SPECviewperf test, it's impossible to know which result represents the reality one would experience in real world use.
Let's move on to design applications.
Design applications have long been the sweet spot for high-end OpenGL graphics cards, and remains somewhat of a last bastion, as Nvidia and now Radeon-based boards using games-oriented technology are capturing significant share in DCC. However, the design market, with less emphasis on texture and more on geometry, seems ideal for the agility and responsiveness shown by the Wildcat in negotiating around state changes and other OpenGL challenges. In contrast, especially with an OpenGL application open on the second monitor, triggering a 50%+ loss of triangle pushing power, high-end mechanical design seems like potential quicksand for the Nvidia based boards.
To assess our board's respective capabilities in this category, we focused on five tests, SPECapc application benchmarks for Pro/Engineer, SolidEdge, and SolidWorks, and two viewsets from the new SPECviewperf tests included Pro/Engineer and Unigraphics. Once again, we ignored the other design-oriented viewsets like Design Review, because we felt that all vendors had already optimized their drivers for these tests, risking results that would not reflect real world performance.
-----------------------------------------------
We should note up front that the Wildcat failed to run Pro/E in any dual monitor tests, as Pro/Engineer 2000i2, the version required for the SPECapc, would not run on the Wildcat with two monitors enabled, irrespective of the test parameters. 3Dlabs attributed this to a problem with Pro/E 2000i2, and considers this a legacy issue, since dual monitors worked well with Pro/Engineer 2002, the current version. We didn't have a copy of Pro/E 2002 on hand, but checked Pro/E developer PTC Corporation certifications list, and found the Wildcat certified on Dell, Compaq and HP Workstations, confirming 3Dlabs claims.
Table 10, Dual Monitor - OpenGL results for design applications Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPEC VP 7 - Pro/E 13.27 -5.42% 10.04 -1.86% 9.88 -1.64% 11.33 -3.74% SPEC VP7 - Pro/E 1 3 4 2 SPEC VP 7 - UGS Score 10.09 -18.63% 7.86 -32.28% 8.04 -26.70% 8.88 -2.47% SPEC Viewperf Ranking 1 2 3 4 Pro-E Rank - Score DNF DNF 4.93 -4.27% 4.92 -3.15% 4.43 -1.77% Pro-E Rank - DNF DNF 1 2 3 SolidEdge - Score 3.52 -2.93% 3.01 -6.99% 3.10 -4.24% 3.33 0.25% SolidEdge - Rank 1 4 3 2 SolidWorks - Score 3.02 -0.66% 2.64 -11.11% 2.65 -14.24% 2.71 -6.55% SolidWorks - Rank 1 4 3 2 MCAD Average Rank 1.00 2.8 3 2.60 Note: DNF stands for Did Not Function
Table 11, Dual Monitor - Non-OpenGL results for design applications Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPEC VP 7 - Pro/E 12.83 -8.55% 10.14 -0.88% 9.97 -0.70% 11.32 -3.82% SPEC VP7 - Pro/E rank 1 3 4 2 SPEC VP 7 - UGS 10.10 -18.55% 10.90 -6.03% 10.42 -5.01% 8.85 -2.71% SPECviewperf - UGS 3 1 2 4 Pro-E Rank - Score DNF DNF 4.96 -3.69% 4.86 -4.33% 4.44 -1.55% Pro-E Rank - DNF DNF 1 2 3 SolidEdge - Score 3.60 -0.72% 3.11 -6.38% 3.03 -3.66% 3.37 -6.36% SolidEdge - Rank 1 3 4 2 SolidWorks - Score 3.03 -0.66% 2.61 -12.12% 2.64 -14.56% 2.74 -5.52% SolidWorks - Rank 1 4 3 2 Average Rank - MCAD 1.50 2.4 3 2.60 Note: DNF stands for Did Not Function
-----------------------------------------------
Overall, regardless of the type of application open in the second window, Wildcat dominated, winning seven of the eight tests completed. More impressive was that Wildcat showed very little degradation in the SPECapc tests, losing a maximum of 3% of performance as compared to its single monitor scores. This is reasonably consistent with raw performance scores, since these tests are more geometry than fill rate intensive, but contradicts the significant drop in performance seen on the wireframe primitive tests.
FireGL was a surprising second place finisher, performing very well in the SolidWorks and SolidEdge benchmarks under both scenarios. This makes the picture much brighter for design than for DCC.
In four of these five design-oriented tests, both Nvidia boards showed little difference between OpenGL and non-OpenGL tests, breaking the pattern we saw throughout virtually all other testing. More importantly, though both boards performed well in Pro/E SPECapc tests, they trailed both the Wildcat and FireGL in SolidEdge and SolidWorks tests.
Both Nvidia boards lost much more ground to their single monitor results, especially with an OpenGL application open on the second monitor. Even with Internet Explorer open in the second window, however, neither Nvidia card recovered sufficiently to mount a serious challenge.
Let's move on to our final testing category, Dual Monitor – Spanned.
In these tests, we attempted to span the application across both monitors and then duplicate our single monitor tests. For this, we disabled nView for the Nvidia boards, and used Max button management for the FireGL as shown in Figure 3. With the Wildcat we simply stretched the application to the full double monitor surface.
Unfortunately, configuring the application across both monitors didn't work with the SolidEdge or SolidWorks SPECapc tests, which run from the command line and default to a single window. Ditto for both the old and new SPEC Viewperfs.
However, the Pro/E and both 3ds max tests ran fine across both monitors, except for graphics card-specific problems noted below. For our Lightwave and Maya ad hoc tests, we centered the display so that it precisely corresponded with the break in the two monitors, and then ran our animation playback test suites.
Table 12, Dual Monitor - Spanned tests Wildcat Q4 900 Q4 750 FireGL Score Delta Score Delta Score Delta Score Delta SPECapc 3ds Max 3.91 -39% 7.24 7.10% 6.97 7.73% DNF Rank 3 1 2 3ds Max Maxbench 17.00 -22.90% 39.07 -4.07% 37.00 -2.86% 22.93 -26.11% Rank 4 1 2 3 SPECapc - Pro/E Score DNF 4.91 -4.66% 4.89 -3.74% 4.03 -10.64% Rank 1 2 3 Lightwave - fps 12.66 -10.33% 12.91 -3.20% 12.91 -5.03% 13.10 -2.72% Rank 4 3 2 1 Maya - fps DNF 11.56 -47.60% 11.14 -49.09% 12.36 -24.26% Rank 3 2 1
-------------------------------------------------
One of the first anomalies we noted was the FireGL's 2048x2048 3D rendering limitation. We saw this immediately when we tried to span across our two 1280x1024 desktops, and had 3ds max and Lightwave snapping back to about 60% of the second monitor. We pinged our ATI support contact and got the following reply.
The FireGL 8800 has a 3D rendering limitation of 2048x2048. The resolution you are running with 2x1280x1024 is 2560x1024 which exceeds the 3D rendering limit, so we will force the window smaller to stay within this limitation.
As we discussed in part 1, ATI says that few of their customers encounter this problem, because most tend to run different applications in the separate monitors. Probably true enough, but this is a concern for users who need complete dual monitor real estate, and a serious competitive disadvantage versus the other products, which spanned just fine.
Our contact posited that this limit also caused the FireGL to DNF in the 3ds max SPECapc, though the route was circuitous. Specifically, the test aborted just after liftoff, reporting that the board didn't support the required minimum of 8 lights in the viewport. To this question, our contact replied:
I suspect the test is trying to force full screen which would exceed the resolution limitation and is encountering results that it cannot deal with and is interpreting this as a lighting limitation of the card.
Whatever the cause, this problem did not prevent us from running the Maxbench test, indicating that the FireGL works well with 3ds max up to the 2048 limit; it simply can't run the 3ds max SPECapc benchmark spanned across both screens fully.
In other 3ds max SPECapc tests, we noticed immediately that the two Nvidia cards were actually faster in span mode than on single monitor tests. Our immediate response was to retest in single monitor mode, which verified our initial results.
Then, we watched carefully throughout the automated SPECapc test, and saw that 3ds max was zooming in on all animations to support the much wider aspect ratio, cutting off a significant portion of the animation playing on screen. This was particularly apparent with the juggler sequence, shown in Figure 4.
What's interesting is how the Nvidia boards reacted to this reduced animation compared to the Wildcat. Both Nvidia cards played the juggler sequences about 8 seconds faster than when tested on a single monitor, reducing a 20 second playback time down to 12 seconds in all juggler related tests. This makes sense, given that less animation is actually displayed on screen, which means less work.
In contrast, however, the Wildcat's playback time for this same sequence increased from 21 seconds to 72 seconds, accounting for much of the 133 seconds added when going from solo to span mode. This is yet another area where Nvidia's custom 3ds max driver showed a remarkable ability to boost performance under unusual conditions, though a smaller effective window was displayed, where 3Dlabs' driver did just the reverse.
-----------------------------------------------
Remember to discount the FireGL's narrow victory in the Lightwave and Maya tests by the 2048x2048 rendering limitation, which means it pushed fewer pixels than the other cards. In addition, we should note two problems experienced with the Wildcat in these tests. The first occurred in Lightwave, where the board failed to display the animation timeline on the second monitor, truncating the display at the end of the first monitor. Playback controls displayed normally, however, so you could play and stop the animation, you just couldn't see the second part of the timeline.
Second was more serious, the inability to run Maya fully spanned across two monitors. The Wildcat had no problem displaying 3ds max and Lightwave across two monitors, and Maya spanned to the full 2560x1024 on the two Nvidia cards, and up to the FireGL's 2048x1024 rendering limit. However, with the Wildcat, Maya kept snapping back to 1280x1024 resolution whenever we attempted to stretch the application. We asked 3Dlabs about this issue and they confirmed the problem, but had no solution.
The FireGL also experienced problems with the Pro/E test, spewing massive amounts of screen garbage in any window that spanned more than one monitor, while any window contained in a single monitor displayed normally (See Figure 5). ATI attributed these problems to the aforementioned 2048 rendering limitation, stating that any screen that strayed beyond these boundaries would become corrupted. Either way, Pro/E developers seeking to span dual monitors should probably select another board.
Overall, the lack of consistent, across the board results makes ranking in this category somewhat less important than the stability issues raised. Nvidia has long suffered from an impression that their drivers were not as advanced as their graphics chips, but the lack of a DNF for either board in this category speaks volumes about how far they've come, notwithstanding some of the higher level issues we experienced with nView.
Let's move on and see where all this data takes us.
Table 13, Summary of Results Wildcat Quadro 4 900 Quadro 4 750 FireGL 8800 Single Monitor SPECapc for 3ds Max 3 1 2 4 Other DCC 1.00 2.67 2.67 3.67 Design 1.20 2.60 3 3 AutoCAD 4 1 2 3 Dual Monitor 3ds Max - OpenGL 2.67 1.33 2.33 3.33 3ds Max - Non-OpenGL 2.67 1.33 2.33 3.67 Other DCC - OpenGL 2.5 2 3 2.5 Other DCC - Non-OpenGL 2.5 2.5 2.5 2.5 Design - OpenGL 1 2.8 3 2.6 Design - Non-OpenGL 1.5 2.4 3 2.6
--------------------------------------
3Dlabs Wildcat III 6110
The Wildcat III 6110 won all design oriented category rankings, both single and dual monitor, often by significant margins, making it the board of choice for those who value performance over price. In most DCC-oriented tests, however, performance waned, especially in dual monitor tests.
We wouldn't throw the Wildcat III permanently out of contention for DCC, however, because it's obvious that their 3ds max plug-in left a lot of performance on the table compared to Nvidia. 3Dlabs made some serious noises about upgrading their plug-in during our conversations; it will be interesting to see if they take this step and how much performance they will gain from it.
3Dlabs doesn't offer dual monitor utilities, which we didn't miss at all during our tests, preferring to use the basic Windows controls over either Nvidia's or ATI's utilities. While generally very stable, the Wildcat couldn't span Maya greater than a single screen width, and also had problems with a disappearing animation slider when spanning Lightwave across multiple monitors.
Nvidia Quadro 4 750 and 900
Both Nvidia boards emerged as digital content creation champs, though behind the Wildcat for more traditional design. The performance difference between the 750 and 900 was generally pretty minimal; unless you absolutely need dual digital monitor output, you'll find the 750 delivers greater bang for the buck.
We liked Nvidia's generally efficient drivers, though certain design decisions, like defaulting to Vertical Synch on, drove us crazy during our tests. Still, both boards finished all tests, without the screen anomalies experienced by the FireGL or the application incompatibilities suffered by 3Dlabs.
Nvidia also appears to have given the most thought to dual monitor operation. We saw this in many areas, most notably the almost 50/50 performance allocation between foreground and background applications in our dual monitor simultaneous application tests.
ATI FireGL 8800
The FireGL showed occasional flashes of brilliance, particularly in dual monitor design oriented tasks, but price, rather than performance, is clearly its most attractive option. The FireGL was the only board with a rendering limitation (2048x2048) that prevented it from supporting two complete dual windows, a factor those planning on spanning their applications over dual monitors need to consider.
We liked ATI's HydraVision dual monitor utilities; though we found them a bit peripatetic with too many different tabs and windows. Operation was generally stable, except for the occasional need to reboot so the utilities could properly identify one or both of our test bed monitors (allowing us to set the appropriate refresh rate).
That ends our three part series on OpenGL cards. We realize we presented an enormous amount of data, and we hope you have a better understanding of the relative merits of the tested cards.
Copyright © 2002 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in ExtremeTech.
The Look of OpenGL
Creating eye-catching 3-D content requires the right tools, both hardware and software. With CGI movies such as Toy Story and Jurassic Park setting the bar for smooth animation and with computers being used for all facets of mechanical design, it's clear that your product better be perceived as a killer–but not a killer of productivity or your budget.
When nVidia launched its Quadro product line in November 1999, the insular workstation graphics market was caught by surprise with the products' shockingly fast performance and aggressive price. Some segments of the workstation market, such as game development and other low-end digital content creation, have standardized on cards using Quadro2 Pro chips or even cards based on its less expensive, game-oriented sibling, the GeForce2 Ultra.
Other segments such as CAD/CAM, visualization, and film animation were generally more traditional, preferring solutions from familiar vendors. But few design professionals could afford to ignore the startling price/performance advantage offered by nVidia-based products.
Since the launch, nVidia has made significant strides with its workstation line, but Quadro development has taken a back seat while nVidia ships its next-generation graphics-processing unit (GPU).
In fact, though previous versions of nVidia's workstation chips quickly followed the shipment of game chips upon which they were based, nVidia may not release a workstation version of the new GPU. This means that the current Quadro2 Pro chip, available through retail channels only in the ELSA Gloria III, may remain the top nVidia workstation component for some time.
At the same time, nVidia's competition hasn't been standing still. SonicBlue recently shipped the Fire GL2 and Fire GL3, based on new geometry and raster engines from IBM. Leveraging technology purchased from Intergraph, 3Dlabs just launched the Wildcat II 5110 (available only through workstation OEMs).
To compare these new products, we tested the ELSA Gloria III, SonicBlue Fire GL2 and Fire GL3, and the 3Dlabs Wildcat II 5110 on a Dell Precision 330 workstation with a 1.5-GHz Pentium 4. We ran a suite of benchmark tests, including six Indy3D 3.0 tests, five SPEC Viewperf tests, and SPEC Solidworks 2000. We also sat with the CTO of Side Effects Software, developer of the special-effects program Houdini. To assess how the respective cards responded to typical development tasks, we built, manipulated, and textured a model consisting of 169,293 polygons and 677,172 vertices (169,580 unique).
In general, these tests revealed that nVidia's drivers were more stable than we experienced last August, with only minor interface anomalies in one application. Yet the two Fire GLs and especially the Wildcat card outperformed the Gloria III on the tests. Application testing also revealed several Quadro2 Pro chip shortcomings, including noticeable on-screen latency when working in wireframe mode with anti-aliasing engaged.
As always, choosing the right card depends not only on performance but also on budget, hardware features, and factors such as operating system support and multiple monitor display.
Copyright © 2004 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in PC Magazine.
When nVidia launched its Quadro product line in November 1999, the insular workstation graphics market was caught by surprise with the products' shockingly fast performance and aggressive price. Some segments of the workstation market, such as game development and other low-end digital content creation, have standardized on cards using Quadro2 Pro chips or even cards based on its less expensive, game-oriented sibling, the GeForce2 Ultra.
Other segments such as CAD/CAM, visualization, and film animation were generally more traditional, preferring solutions from familiar vendors. But few design professionals could afford to ignore the startling price/performance advantage offered by nVidia-based products.
Since the launch, nVidia has made significant strides with its workstation line, but Quadro development has taken a back seat while nVidia ships its next-generation graphics-processing unit (GPU).
In fact, though previous versions of nVidia's workstation chips quickly followed the shipment of game chips upon which they were based, nVidia may not release a workstation version of the new GPU. This means that the current Quadro2 Pro chip, available through retail channels only in the ELSA Gloria III, may remain the top nVidia workstation component for some time.
At the same time, nVidia's competition hasn't been standing still. SonicBlue recently shipped the Fire GL2 and Fire GL3, based on new geometry and raster engines from IBM. Leveraging technology purchased from Intergraph, 3Dlabs just launched the Wildcat II 5110 (available only through workstation OEMs).
To compare these new products, we tested the ELSA Gloria III, SonicBlue Fire GL2 and Fire GL3, and the 3Dlabs Wildcat II 5110 on a Dell Precision 330 workstation with a 1.5-GHz Pentium 4. We ran a suite of benchmark tests, including six Indy3D 3.0 tests, five SPEC Viewperf tests, and SPEC Solidworks 2000. We also sat with the CTO of Side Effects Software, developer of the special-effects program Houdini. To assess how the respective cards responded to typical development tasks, we built, manipulated, and textured a model consisting of 169,293 polygons and 677,172 vertices (169,580 unique).
In general, these tests revealed that nVidia's drivers were more stable than we experienced last August, with only minor interface anomalies in one application. Yet the two Fire GLs and especially the Wildcat card outperformed the Gloria III on the tests. Application testing also revealed several Quadro2 Pro chip shortcomings, including noticeable on-screen latency when working in wireframe mode with anti-aliasing engaged.
As always, choosing the right card depends not only on performance but also on budget, hardware features, and factors such as operating system support and multiple monitor display.
Copyright © 2004 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in PC Magazine.
Top Tip: What are OpenGL, Direct3d, DirectX, etc.?
Tips used for Top Tips come from the ExtremeTech forum and are written by our community.
Question from MutantsForNu "Can anyone give a quick summary of what all these software pieces are and how they interact w/ each other? I've installed DirectX, but I don't recall installing the others. Are they just graphic api's that DirectX interprets? Do they come built into windows? Just curious, thanks! "
Answer from LinksMaster "A quick summary you say? Well, this is as quick as can be without being too brief.
First, a bit of clarification: Direct3D is a subset of DirectX. DirectX contains Direct3D which is the primary graphics handling portion of DirectX. OpenGL, on the other hand, is it's own API.
A game developer, or any graphics rendering programmer, can choose whether to call into use the DirectX (Direct3D) or OpenGL APIs. And if they want to be totally safe they can program seperate modules that let you choose which API to use.
Advertisement
(The final version of the old Unreal game when fully patch to v226f let you choose your API for running the game. Some of the APIs are now obsolete or incorporated into the DirectX or OpenGL APIs.)
#1 DirectX (containing Direct3D) and OpenGL are APIs. API = Application Program Interface http://www.webopaedia.com/TERM/A/API.html
An API, application program interface allows developers, in this case Game Developers and Video/CAD developers among others, to use predefined function calls to make the overall effort of programming a GAME or a CAD program easier. So, DirectX and OpenGL define ways of rendering images. And they provide an intermediate layer of control between the Video Hardware (Videocard) and the Video Software (Game, CAD program, etc). This predefined control layer eases the development of the Video Software such as games.
It's faster and easier for developers to write code while using an API which will handle certain tasks for the developer. Otherwise the programmers on the development team would have to do all the graphics rendering in their own code.
#2 By default, Windows Systems from Windows 95 on up have contained early versions of both APIs at some level.
So, they don't have to be installed per se. And, while the DirectX and OpenGL APIs do not have to be initially installed, they do however, have to be updated from time to time.
#3 This is where we have to distinguish the differences between DirectX and OpenGL.
API - OpenGL is purely a Graphics rendering API. Period. So, it only deals with graphics.
API - DirectX contains Graphics (Direct3D), Sound (DirectSound) and even Network (DirectPlay) APIs all wrapped into a single package.
#4 Some background on the DirectX and OpenGL
The Direct3D API (now part of DirectX) was created by Microsoft in response to OpenGL. So, Microsoft created Direct3D which it perceived to be simpler and which Microsoft decided it would support in the hopes that it would one day become more robust than OpenGL and, hence, replace it.
The OpenGL API was created by SGI (Silicon Graphics) in the 1980s. In the beginning it was a proprietary API which SGI used to leverage their superior Graphics Render capabilities. Over time however, they realized that to become an industry standard they would have to openly license it and begin allowing other companies in the industry to help define specifications for it.
#5 And, so we come to our world TODAY
So, now we have both DirectX and OpenGL. OpenGL changed into a freely available industry standard openly licensed. And DirectX, to some extent followed suit.
However, DirectX remains primarily a Microsoft standard. But some would argue with DirectX 9.0 that it is now superior to OpenGL... at least until the next revision of OpenGL is released.
#6 Updating OpenGL and DirectX
Updating OpenGL: OpenGL is now primarily packaged with your Video Card's Drivers. So, essentially everytime you update your Video Card drivers you are updating your Open GL API as well. That does NOT mean it's a NEW version of OpenGL every time. It simply means that you'll keep installing it each time you perform a driver update.
So, update your Videocard Drivers and you are up to date with OpenGL.
Updating DirectX: DirectX is a large API now with it's Audio, Video and LAN feature sets growing very large but very robust. It is intended to handle ALL things SEEN, HEARD and TRANSMITTED. So it is a MUCH LARGER API than OpenGL. As a result it is updated as a wholly seperate package. Microsoft includes a base version on every copy of Windows. And if you want the newest you have to download it and install it seperately as you have done.
So, to update DirectX (Direct3D, DirectSound and DirectPlay) you have to go to Microsoft's website and download it from them. http://www.microsoft.com/directx
And that's that. Quick enough? Heh heh. "
Answer from wrburns "Yes, OpenGL is a descendant of SGI's IRIX API. The trademark is owned by SGI. I personally love OpenGL, because you can program a game with OpenGL/GLUT and expect it to work on any platform (so long as it doesn't use "native" APIs). I'm working on a 3D chess game, and we have it running on Linux, Mac OS X, and Windoze - all using the same graphics code. OGL is pretty cool. To get the sound, you have to use something like SDL, though, so DirectX is nice in that it integrates everything. But you can accomplish pretty much the same thing by using OpenGL, SDL, and Apple's OpenPlay - and your code will work on virtually every platform."
Copyright © 2003 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in ExtremeTech.
Question from MutantsForNu "Can anyone give a quick summary of what all these software pieces are and how they interact w/ each other? I've installed DirectX, but I don't recall installing the others. Are they just graphic api's that DirectX interprets? Do they come built into windows? Just curious, thanks! "
Answer from LinksMaster "A quick summary you say? Well, this is as quick as can be without being too brief.
First, a bit of clarification: Direct3D is a subset of DirectX. DirectX contains Direct3D which is the primary graphics handling portion of DirectX. OpenGL, on the other hand, is it's own API.
A game developer, or any graphics rendering programmer, can choose whether to call into use the DirectX (Direct3D) or OpenGL APIs. And if they want to be totally safe they can program seperate modules that let you choose which API to use.
Advertisement
(The final version of the old Unreal game when fully patch to v226f let you choose your API for running the game. Some of the APIs are now obsolete or incorporated into the DirectX or OpenGL APIs.)
#1 DirectX (containing Direct3D) and OpenGL are APIs. API = Application Program Interface http://www.webopaedia.com/TERM/A/API.html
An API, application program interface allows developers, in this case Game Developers and Video/CAD developers among others, to use predefined function calls to make the overall effort of programming a GAME or a CAD program easier. So, DirectX and OpenGL define ways of rendering images. And they provide an intermediate layer of control between the Video Hardware (Videocard) and the Video Software (Game, CAD program, etc). This predefined control layer eases the development of the Video Software such as games.
It's faster and easier for developers to write code while using an API which will handle certain tasks for the developer. Otherwise the programmers on the development team would have to do all the graphics rendering in their own code.
#2 By default, Windows Systems from Windows 95 on up have contained early versions of both APIs at some level.
So, they don't have to be installed per se. And, while the DirectX and OpenGL APIs do not have to be initially installed, they do however, have to be updated from time to time.
#3 This is where we have to distinguish the differences between DirectX and OpenGL.
API - OpenGL is purely a Graphics rendering API. Period. So, it only deals with graphics.
API - DirectX contains Graphics (Direct3D), Sound (DirectSound) and even Network (DirectPlay) APIs all wrapped into a single package.
#4 Some background on the DirectX and OpenGL
The Direct3D API (now part of DirectX) was created by Microsoft in response to OpenGL. So, Microsoft created Direct3D which it perceived to be simpler and which Microsoft decided it would support in the hopes that it would one day become more robust than OpenGL and, hence, replace it.
The OpenGL API was created by SGI (Silicon Graphics) in the 1980s. In the beginning it was a proprietary API which SGI used to leverage their superior Graphics Render capabilities. Over time however, they realized that to become an industry standard they would have to openly license it and begin allowing other companies in the industry to help define specifications for it.
#5 And, so we come to our world TODAY
So, now we have both DirectX and OpenGL. OpenGL changed into a freely available industry standard openly licensed. And DirectX, to some extent followed suit.
However, DirectX remains primarily a Microsoft standard. But some would argue with DirectX 9.0 that it is now superior to OpenGL... at least until the next revision of OpenGL is released.
#6 Updating OpenGL and DirectX
Updating OpenGL: OpenGL is now primarily packaged with your Video Card's Drivers. So, essentially everytime you update your Video Card drivers you are updating your Open GL API as well. That does NOT mean it's a NEW version of OpenGL every time. It simply means that you'll keep installing it each time you perform a driver update.
So, update your Videocard Drivers and you are up to date with OpenGL.
Updating DirectX: DirectX is a large API now with it's Audio, Video and LAN feature sets growing very large but very robust. It is intended to handle ALL things SEEN, HEARD and TRANSMITTED. So it is a MUCH LARGER API than OpenGL. As a result it is updated as a wholly seperate package. Microsoft includes a base version on every copy of Windows. And if you want the newest you have to download it and install it seperately as you have done.
So, to update DirectX (Direct3D, DirectSound and DirectPlay) you have to go to Microsoft's website and download it from them. http://www.microsoft.com/directx
And that's that. Quick enough? Heh heh. "
Answer from wrburns "Yes, OpenGL is a descendant of SGI's IRIX API. The trademark is owned by SGI. I personally love OpenGL, because you can program a game with OpenGL/GLUT and expect it to work on any platform (so long as it doesn't use "native" APIs). I'm working on a 3D chess game, and we have it running on Linux, Mac OS X, and Windoze - all using the same graphics code. OGL is pretty cool. To get the sound, you have to use something like SDL, though, so DirectX is nice in that it integrates everything. But you can accomplish pretty much the same thing by using OpenGL, SDL, and Apple's OpenPlay - and your code will work on virtually every platform."
Copyright © 2003 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in ExtremeTech.
Sunday, May 20, 2007
| The End : The Game | RC1 released
This is the first beta release of the game created by me for a school project called "| The End : The Game |". The project is hosted @ SourceForge.net. You can download the source and binaries currently only for Win32 platform, but i am working on porting to Linux & Mac platforms (although it shouldn't be really complicated, and i'm on the half way of doin' it). The game actually is a Quake clone, but c'mon this is just an alpha release and i have some really nice ideas (but no time to make them work), so stay tuned...
If you have any question concerning the build process or just any question (including the meaning of life) you can contact me at
key.mit@gmail.com.
PS: sorry for the 'redirection' from sourceforge, but my site @sf.net is not ready...
http://sourceforge.net/projects/theend
drop me a comment on what you think.
screenshots :
If you have any question concerning the build process or just any question (including the meaning of life) you can contact me at
key.mit@gmail.com.
PS: sorry for the 'redirection' from sourceforge, but my site @sf.net is not ready...
http://sourceforge.net/projects/theend
drop me a comment on what you think.
screenshots :
game launcher
game launcher with licence
loading screen
GUI of the game (CEGUI)
credits screen
in-game screenshot
game over screen
in-game screenHUGE index Free Vectors!
New site with a ton of free vectors available for download.
read more | digg story
Novell tricks Microsoft into killing MS's patent claims against Linux users
Heh, remember when Microsoft agreed to distribute those SuSE GNU Linux coupons? Well, those coupons have no expiration date, so if even one person uses one of those coupons to get SuSE GNU Linux distros after the GPL 3 goes into effect in July, BINGO, Microsoft is covered by the GPL 3, and its patent claims against any user of GNU Linux are dead.
read more | digg story
6 Degrees of Computer Science
Pretty graph of differences between Computer Science, Computer Engineering, Software Engineering, and other thesaurus terms that confuse University bound students.
read more | digg story
Watch Diggs Appear in Real-Time on Brian Shaler's Map of the Digg Community
In this Digg data visualization, icons are placed at users' coordinates on the map in real-time as they Digg stories. You can then click on the icon to reveal the story information.
read more | digg story
Top 5 javascript frameworks
a list of the top 5 javascript frameworks and features.
read more | digg story
Mmm! I love raisins made with SELECT * FROM [Equipment Table]! (pic)
How come my chocolate covered raisins never come with any SQL?
read more | digg story
30 Scripts For Galleries, Slideshows and Lightboxes
Family photos, vacation snapshots or creative artistic works: whatever images you have to present, you can present them in a variety of ways. On a big screen, in slide shows or in a thumbnails gallery. However, to convey the message of presented data effectively, it’s important to offer it in an attractive and intuitive way.
read more | digg story
Digg Expose = DIGG + Snap Preview Shots
It never ceases to amaze me the cool stuff that people are doing with APIs. This little mashup was found on the YourMinis site. Basically a realtime feed of DIGG posts illustrated using Snap Preview Shots, with some layout and sorting tools to adjust the way it renders the previews as they stream in.
read more | digg story
Most realistic CG render
This has to be the best CG I have ever seen. Believe it or not, even the hair is 3D.
read more | digg story
53 CSS-Techniques You Couldn’t Live Without
CSS-based techniques you should always have ready to hand if you develop web-sites. Thanks to all developers who contributed to accessible and usable css-based design over the last few years. We really appreciate it. Show some Love.
read more | digg story
What happens when you take a photo at the right angle?
I normally hate forwarded emails but this one left me laughing. It is a collection of 14 photos that show you what happens when you're holding the camera at just the right angle:
read more | digg story
The Most Hypnotizing Website Ever
Definitely listen with speakers or headphones. The dots are arranged to trigger notes on a chromatic scale when they pass the line. How can something be so creepy yet so cool at the same time?
read more | digg story
Incredibly Strange 3D Rotating Website Menu
When you move the mouse, you orbit this menu. It can get very disorienting. The content of the website is equally confusing.
read more | digg story
How to make sexy buttons with CSS
This tutorial will teach you how to create pretty looking textual buttons (with alternate pressed state) using CSS. Dynamic buttons save you heaps of time otherwise spent creating graphics and will basically make you a happier person at the end of the day.
read more | digg story
Friday, May 18, 2007
Common SEO Mistakes
Search engine optimization has become the focus of many people who have online businesses and for good reason. If you can be noticed and ranked well by search engines, you will be more visible to current and future customers. Optimization is something that so many web publishers are pursuing but in the course of trying to be noticed many are making some huge mistakes. These mistakes can easily be avoided, and many have found these mistakes to be hampering their success by trial and error.
The most common SEO mistakes is to have bad titles for your pages. The reason is titles are the very first thing that the search engine spiders will see when they look at your website. A title should give the spider as well as the visitor a clear idea of what the website is all about. If you can focus your titles, you will then find that your page rank will soar and you will likely have many more customers come your way as a result. A focused site is always a good thing and this includes something that seems as insignificant as a title!
Another common SEO mistake is to have bad content on your website. A couple years ago, web publishers thought that you simply had to have keyword rich content, but today it is known that it is not that easy. You need to have more than the typical how to or vague and useless content on your website if you want to really be optimized for the search engines. You can have keyword rich articles, but be sure that they are informative as this will allow for you to be seen by the search engine spiders but also keep visitors on your site once they click and enter your page!
Linking is anther common mistake that web publishers face. Links are important because the more incoming links a page receives, the more important the search engines view the web page. But, the links have to be good incoming and outgoing links. If you have poor incoming links or there is poor internal linking all of your hard work to obtain links will be in vain. Web publishers have to find a balance and only involve themselves with good links.
These are some of the most common problems that web publishers make when they attempt to optimize their websites for the search engines. SEO is not easy, but if a web publisher avoids these very common mistakes he or she has a leg up on the competition. Remember, optimization is not something that happens over night. Those that rush tend to do more harm than good to their page ranking so take your time a do a good job if you want to succeed.
About the Author
He has performed work for companies such as BCS Website Services, a Richmond VA Web Design Firm. He recommends Richhost.com for Richmond Events, and Red Fern Gifts for collectible gift ideas.
Consumers face tricky decisions as the DVD format war rages on
Hi-def content looks certain to be the way forward, but with 2 different formats available, consumers could either be spoilt for choice or victims of a technological tug of war
With the way that things are going, it is highly unlikely that there will be any eventual winner in the war between Blu-Ray and HD-DVD. With an increasing number of hi-def displays finding their way into people's living rooms, there's a great opportunity to exploit, but the two camps are not interested in sharing this trove, and we could well see a clearly defined line separating the market. What started out as a race to see who could produce the next generation format has turned into a rather large spat between Sony and Philips of Blu-Ray and Toshiba and Hitachi of HD-DVD.
Both formats provide the same end, but just by different means. Hi-definition content is the aim, and there is no doubting the quality that they provide. Unfortunately, consumers could well be the ones to lose out if they adopt early for either one of the formats. Currently, different film studios have signed up for different formats, meaning that films released on the new discs could only be available on one type, and that's no good if you've already spent a lot of money on a player for the other format. Toshiba were the first to enter the hi-def market with their HD-DVD player, and Blu-Ray's presence was confirmed shortly after when Samsung released their first hi-def player. With neither side yielding, the biggest problem facing us all is deciding which format would be best to choose?
At the moment, consumers have a limited range to choose from when it comes to picking a player to watch their preferred format discs. There are only a handful of HD-DVD players, and even fewer Blu-Ray ones. In terms of price, which can be seen as one of the more important factors, the HD-DVD players can be bought for less. The introduction of the PlayStation 3, priced at under £500, can be seen as a victory for the Blu-Ray camp in terms of getting closer to equalling the prices of the HD-DVD players. All the same, not very many people will be able to afford to buy 2 players at over £300 each just so they can cover all bases. Luckily, LG have produced a hybrid player that can handle both formats, and this could be a step in the right direction. It's by no means a perfect system as it's predominantly a Blu-Ray player that can play HD-DVDs, but without some of the advanced features, but with a similar machine announced by Samsung to be produced, manufacturers could well be sensing that there is a market to be served. This isn't a guaranteed solution though, as initial prices are expected to be in excess of £800.
So, it seems that the public will have to settle for either one of the formats after all, at least for the time being. Looking at the statistics, Blu-Ray discs are able to store more information, with one layer being able to hold up to 25GB, compared to HD-DVD's 15GB capacity. This isn't to say that Blu-Ray is superior. For this extra capacity, consumers will have to pay a bit more, with the reason being that they use thinner protective layer on their discs. HD-DVD discs conform to the current DVD trend by using a 0.6 mm thick surface layer, but Blu-Ray uses a miniscule 0.1mm thick surface layer. Using this thinner layer means that current equipment will need to be modified or replaced, where as HD-DVD discs can continue using current tools. The layer also needs to be much more robust to withstand any abuse that gets thrown its way. The fundamental differences between the two technologies cause this variation in layer thickness. The reason Blu-Ray can hold more is because its track pitch is tighter, and thus the pick up aperture is 0.85, weighed against HD-DVD's 0.65. The 0.1mm thick surface layer helps the laser to focus with the 0.85 aperture. All of this goes to prove that the two formats are different, and incompatible, and that if you want more storage, you will have to be able to pay for it.
As mentioned before, the different film studios will also have an impact on which format will become more successful. Buena Vista Home Entertainment, Paramount Pictures, The Walt Disney Company and Warner Brothers have signed themselves up for both camps, but many others have decided to back just one of the formats. HD-DVD has support from New Line Cinema and Universal Studios, and Blu-Ray can rely on 20th Century Fox, MGM Studios and Sony Pictures Entertainment. Blu-Ray also has the added advantage of a few gaming studios, such as Electronic Arts. It won't be easy to predict the quality of films to be produced by differing studios, so it's hard to tell which side has the better support. Seeing as Blu-Ray has more studios signed up, it may well have an edge over HD-DVD.
Early indications appear to suggest that Blu-Ray has managed to get ahead of HD-DVD, with stronger backers and higher storage, but it would still be far too early to write one of these formats off. Higher running costs will only take effect in the future, so whilst early adopters will be quick to nail a flag to a mast, many others will wait and see. If more manufacturers are able to produce hybrid machines, HD-DVD and Blu-Ray may well be able to coexist quite happily together.
About the Author
This article has been brought to you by Laskys, Laskys is a trusted supplier of a wide range of LCD TVs, Plasma Screen TVs and DVD Players.
Firewall & Port Basics
Gaming in general is fun, but there's something about multiplayer gaming that's even more enjoyable. Perhaps it's the satisfaction of realizing that the car you just passed in the last lap is being driven by a real person, like you, and not some computer program.
But the Internet connection that makes gaming so much fun also serves as a doorway through which nefarious hackers can send malicious code, causing havoc with your computer. Broadband users are especially fertile targets for bad seeds. That's why a firewall is so important. A good firewall, such as Internet Connection Firewall (ICF) that comes with Windows XP, protects your computer from attacks.
A firewall works by blocking communication ports that are used to transfer data to and from your PC. However, games (and all applications that work over the Internet) use those ports to communicate. This raises some questions that we frequently encounter on message boards and in the Usenet: how does a firewall affect the performance of online gaming? What do you have to do to enjoy online gaming with a firewall in place? I'll answer these questions in this article.
How Ports Work To get the most out of online gaming through a secure connection, you have to have some idea of how games communicate over the Internet and how a firewall works. Don't worry; this discussion won't get inaccessibly technical. I'll stick to layman's terms. To start with, let's look at how programs talk to each other over the Internet. All Internet-aware programs communicate with each other through ports. What, exactly, is a port?
Think of your Internet connection as a water conduit. But instead of thinking of it as one big pipe, picture it as a conglomeration of thousands of small pipes: 65,535 of them, to be exact. That is the number of Internet ports through which communications can take place.
Different services use different ports--the assignment of which service uses which port is more or less arbitrary. For example, World Wide Web communications use port 80. Why port 80? Because a few years ago, a bunch of Internet-related people got together and decided that that's how it would be. Similarly, SMTP e-mail traffic uses port 25. Those same people decided that that's how that would go, and so on. These and other services use protocols to transmit and receive their data through these ports. Two protocols that they use are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
The 65,535 ports are divided into three groups: Well Known Ports (ports 0 through 1023), Registered Ports (ports 1024 through 49151), and Dynamic or Private Ports (all the rest). A list of port numbers and what services commonly use them is kept up by the Internet Assigned Numbers Authority.
Like other services, the Internet components of games use ports and protocols to communicate over the Internet. When you play Halo online with a bunch of other people, it has to transmit your keyboard and mouse-click data to the server so it can tell when you move around or fire your weapon. In turn it has to transmit world data back to your computer so you can see where other people move so you can aim at them and chase them around. Halo and other multiplayer games like the Quake family, Half-Life and mods such as Team Fortress Classic and the popular Counter-Strike, Medal of Honor: Allied Assault, Battlefield 1942 send their data down ports and listen for data from the same or other ports. Game matchmaker services like GameSpy Arcade also use ports to communicate.
Firewalls block ports. They are, by their very nature, communications- blocking applications. By closing off ports, they prevent malicious entities from gaining access to your computer through your Internet connection. But doesn't that mean they also block traffic for benign applications that you want to have access to the Internet, such as your Web browser, your e-mail application, and online games?
The answer is sort of. Picture a computer firewall in terms of its namesake. A firewall in construction terms is a specially insulated wall between office suites or apartments, which prevents fires in one suite from spreading to the next suite. But sometimes builders want water or electrical conduits to pass through the firewall. That's easy enough--they just poke a hole through the wall, run their conduit through, and insulate around it. Computer firewalls let you do just that. They let you open specific ports while keeping other ports sealed off.
Gaming through ICF So when do you need to open ports? Believe it or not, when you want to play client-server games like Return to Castle Wolfenstein or Call of Duty on a distant server, you don't have to open any ports. That's because firewalls block data coming in, but not going out. When your PC sends handshake data out to the server, a connection is established, and once that connection is fired up, it allows your game to communicate through the firewall.
However, when you wish to host a multiplayer session or play a peer-to-peer game like Age of Empires, you do have to do a little footwork. In the case of starting a server, your PC does not initiate a connection. When you start up a game and choose to host a server, it just sits there and waits for other computers to connect to it. When ICF is in place, those other computers can't connect. In fact, they can't even see that your PC is hosting a server. You'll have to open one or more ports to allow other players to connect to your server. Such is also the case with peer-to-peer games, in which each participant has to connect to everyone else's computer. Thankfully, most games use a client-server implementation.
To open ports in your ICF firewall: 1) Click Start, click My Network Places, and under Network Tasks, click View network connections. 2) Right-click the connection that you use for the Internet, and then click Properties. 3) On the Advanced tab, click Settings, and then click Add. In the Description of service box type a name for the port you're opening. For example, "Halo Server." 4) In the Name or IP address of the computer hosting this service on your network box, type 127.0.0.1. 5) In both the External Port and Internal Port boxes, type the port number you want to open. 6) Click either TCP or UDP, and then click OK. If you're unsure, repeat the process for both protocols.
If you choose to make things easier, you can opt to turn off ICF when hosting a game and turn in it back on when you're done. However, this leaves your computer vulnerable while your PC is acting as the game server.
Which ports do you open? Different games use different ports and some use TCP, some use UDP, and some use both. You can often find out which ports are used by a given game by consulting the game's documentation, its Readme file, or by visiting its Web site and checking the FAQ pages. Some games make port information readily accessible, and for others, it's hard to come by. You might try visiting a game's Usenet group or the message boards at its official site or fan sites and posing the question: which ports do I open to host a server? In some cases, you'll not only have to open ports for the game's own needs, but also to meet the needs of its matchmaker service, so that your server can be listed in other players' server browsers.
Be sure to close the affected ports when you're not hosting a gaming server to keep your connection secure. That sounds like a lot of footwork, but it's worth it to keep your computer safe.
For more information check out http://www.tornadocomputers.com
About the Author
CIO/Sr. Vice President of Tornado Computers, Inc. in Oklahoma City, OK.
Get Started in Game Creation
I've always loved video games, ever since I first played them on a friend's computer in the afternoon after elementary school. There's something almost magical about the fact that we can move images around and interact with virtual worlds, a living fantasy presented for us to interact with however we please. I've also always wanted to make games myself but, until recently, didn't have the technical knowledge to do so. Now, I'm a second year software engineering student, so if I weren't able to code a game without too many dramas there'd be something drastically wrong. But what about the common person: the person for whom the term 'memory leak' conjures up images of their grandfather, 'pipeline' is where the water flows, and 'blitting' is unheard of? Well, everyone can get in on the game creation process, and you don't even need to learn 'real' programming to do so.
So where do games start? With an idea. Games, like all fiction, require an idea to be successful. Sure, in the same way you can just sit down and write a story without foresight, you can jump on in and slap a game together. However, unless you get ridiculously lucky, the best works are usually the ones that have been well thought out beforehand.
There are two methods of planning a project. You can start from a known technological standpoint and build your project on top of that or you can just go for the design, add as many features and ideas as you like, and then remove the ones that you can't use when you've decided on the technology you're going to implement the game with. In general, the second type is probably the best one to go with when designing games. When you're first starting out however, the first option will save you many headaches.
So, for a first game you're going to want a pretty simple idea. Don't get me wrong, crazy-go-nuts game ideas are fantastic, and there should be more of them out there, but you're not going to be able to create a real world simulator with fifty billion virtual people all interacting real time with your actions having a butterfly effect on the future of the virtual universe when it's just your first game. Really. Many people try it; none that I know of have succeeded. Imitation is the best way to start out. Simple games such as 'Space Invaders', 'Tetris', 'Pacman' or even 'Pong' are great places to start. All are largely simple to create but have some inherent challenges. 'Pacman' for example, requires path finding for the ghosts. I recommend that you start even simpler than that for your very first attempt. 'Space Invaders' is a nice point to jump in. You can make a simple, complete game without much effort and it's almost infinitely extensible.
If you're stuck for an idea, pick a genre that you enjoy. Do you love adventure games such as 'Monkey Island', 'Grim Fandango', 'Space Quest', 'King's Quest' etc.? Design one of those. Are you into fighting games like 'Street Fighter', 'Tekken', 'Soul Calibur', 'Mortal Kombat' and so on? Come up with an idea for that. Do you like first person shooters such as 'Quake', 'Half Life' or 'Doom'? I don't recommend it as a first project, but you can always give it a go. Feel free to be as generic as you like, this is a learning experience after all.
Now that you have your idea it's time to flesh it out. Don't worry about the technology or the fact that you may not know how to actually implement a game just yet, just grab yourself some paper and a pencil and go crazy with ideas. Describe the main characters, game play, goals, interactions, story, and key mappings, anything you can think of. Make sure you have enough detail so that someone can read through the notes and play through the game in their head with relative accuracy. Changing game design during the coding process is almost always a bad idea. Once it's set, it should remain set until the tweaking phase (I'll go into this more later) or you're likely to enter 'development hell', where the project goes on and on; more and more work is done with less and less outcome.
At the end of this period of your game creation, you should have the following:
-A written outline of the game's characters and possibly a sketch or two (be they space ships, yellow circles, cars or the prince of the dark kingdom of Falgour, you need to know who or what the player will be and who they will compete against) -A written outline of the story (if there is one, this isn't too vital for 'Space Invaders' or 'Tetris', but for 'Uber Quest: An Adventure of Awesomeness' it's a really good idea) -A description of game play, written or storyboarded. Storyboards are visual representations of ideas. Draw your characters in actions, with arrows showing the flow of action and short written descriptions detailing the events occurring in your image (because some of us aren't fantastic artists and our images can be a little… open to interpretation…)
Now that you have a fleshed out idea, it's time to work out how this will all get put together. If you've gotten to this point and are worried that you're going to have to spend years learning complex programming languages in order to implement your idea, fear not! Others have already done the hard yards for you. There are many RAD (Rapid Application Development) Tools available for game creation, a number of which are available for free online. Some of them still require you to learn a 'scripting language' (a simplified programming language made for a specific task) but in general this isn't too complicated or involved. I've compiled a brief list of some of these I have found at the end of the article. The free ones are listed first, organized by game genre.
Well, that should be enough to get you started in the creation of your game. The most important thing to remember once you've gotten this far is that you need to complete your game. Many people start a project and then lose interest and it fails, or they keep moving on to one new project after another without finishing anything. Start small, build a working (if simple) game that is, above all else, complete. When you get to this stage you will always have a huge number of things that you wish to change, fix etc. but you'll get a great feeling from knowing that it is, in its way, finished.
From this point, you can start the tweaking phase. Play your game a few times and ask others to do the same. Take note of what isn't fun or could be better and change things here. At this stage, it is more important than ever to keep backups of previous versions so that if a change doesn't work you can go back and try something different without losing any of your work. It is at this point that you can add all new features, improve graphics and sounds, whatever you please, safe in the knowledge that you're working on a solid foundation.
When you're happy with your game, why not share it with the world? There are many cheap or free places out there for you to host your files on and then you can jump on link lists and forums and let everyone know about your creation. Well, I hope that this has been a helpful introduction into the art of creating games. It's a great deal of fun, and can open whole new avenues of creative expression for you to explore. Jump in and have fun!
Links: General Game Creation: (Tools that allow easy creation of many different game types) Game Maker, MegaZeux.
Adventure Games: (Games such as Monkey Island, King's Quest, Space Quest etc.) Adventure Game Studio, AGAST, 3D Adventure Studio, ADRIFT (for text adventures).
Role Playing Games (RPGs): (Games such as Final Fantasy, Breath of Fire, Diablo) OHRPG, RPG Toolit.
Fighting Games: (Games such as Street Fighter, Mortal Kombat, Tekken, Soul Calibur etc.) KOF91, MUGEN (unfortunately the site is largely in French).
Side-Scrolling Games: (Games such as the 2D Mario Games, Sonic the Hedgehog, Double Dragon etc.) The Scrolling Game Development Kit.
There are many others available as well. One particularly useful site for finding game creation tools is: http://www.ambrosine.com/resource.html
Also of note, although not freeware, are the excellent game creation tools available by Clickteam, Klik and Play and The Games Factory in particular are the programs to have a look at and download the free demos of.
If you really want to do things right and program the game yourself, there are some excellent programming resources available at the following locations:
Java Game Programming:
http://fivedots.coe.psu.ac.th/~ad/jg/
http://www.gamedev.net/reference/articles/article1262.asp
http://javaboutique.internet.com/tutorials/Java_Game_Programming/
Visual Basic Game Programming: http://markbutler.8m.com/vb-tutorial.htm
C++ Game Programming:
http://www3.telus.net/alexander_russell/course_dx/introduction_dx.htm
http://www.rit.edu/~jpw9607/tutorial.htm
General Information:
http://www.gamedev.net/
http://www.gamasutra.com/
About the Author
Daniel Punch M6.Net
The Future of Video Games
I've recently been thinking about where video games could be going in the future. I'm hoping to work in the game industry one day after I've finished university study and I've been wondering about it a lot. What do I want to see happen in the future? Well I may not have too many answers right now, but I have come up with a few ideas that I think may come into 'play' in the not too distant future.
Firstly forget Virtual Reality, as we know it. They've tried VR goggles and they made a lot of people sick in doing so. It's probably never going to work very well in its current form. They're still around and you can still buy them but they really don't seem to be taking off. It will probably take a lot to get people totally immersed and involved in a new form of game play. It's threatening to lose touch with the outside world and the people around you aren't going to appreciate it much either. The Sci-fi neural implants are also both a long way off and not likely to be accepted by a majority of the general populace without some severe marketing and luck. I for one am not planning on going through brain surgery just to have a computer attached to my head. In fact I never want anyone to able to plug into my brain.
A technology that was brought to my attention by a zealous presenter at the local 'Science and Technology Centre' (a sort of science museum aimed at making science fun for children and juvenile adults such as yours truly) is that of 'Augmented Reality'. Augmented Reality is essentially the overlaying of virtual elements onto the real world, such as a pair of transparent glasses that can display certain elements over the top of what is actually there. I agree with the presenter in that this could indeed have some awesome potential. Forget all the socially beneficial applications such as workmen being able to view underground pipes before digging, think about it from a games point of view. This technology could provide gamers with the ability to run around looking like complete idiots shooting at things that aren't actually there and that no one else can see, kind of like in the film 'They Live!' The upside to this is that it would be a lot of fun. A group of people from the University of South Australia created the 'ARQuake' project, http://wearables.unisa.edu.au/projects/ARQuake/www/, merging the classic shooter Quake with this Augmented Reality technology. Again, this technology may not ever become overly popular, but it would be entertaining to play with.
Technology has driven the games industry for a long time with new games always trying to keep one step ahead of the competition. It started way back at the dawn of technology and it continues to this day. 2D graphics gave way to 3D and 3D is becoming ever better. Graphics are starting to lose the ability to impress like they once did. The step between Quake 2 and 3 was amazing, but DOOM 3 while being visually very impressive isn't leaps and bounds ahead of its competitors in the same way new games used to be. 2D graphics encountered a similar problem; there comes a point where you just can't do much more with graphics technology. It is this that turns graphics from striving for technological achievement to becoming art. It is my hope that we will start turning away from tech demos and return to game play and making great entertainment. Games such as Zelda: The Wind Waker or The Sims that strive to show greater depth of character through simplifying the game enough to portray emotions will hopefully become more common (and more fun… but that's just one person's view…). Technology plays a certain part in the conveying of emotions and story but it's quite hard to focus on everything at once. When technology is easier and less essential to game sales we'll hopefully see an increase in games that cast a lasting impression.
Somewhat unfortunately the rise of the 'Casual Gamer' will probably lead to more simplistic games being released. While personally I would love to see depth of story and characters, there are a significant number of players out there who want to pick up a game for twenty minutes or so, have a bit of fun, and then put it down until another time. These gamers are generally less interested in the latest greatest technology and more interested in a 'fast food' kind of entertainment that satisfies the moment, despite the lack of quality or the lasting effects. Hopefully the two game types can co-exist peacefully although recently it has been seen that some developers are cutting down on some of the planned depth of a title in order to accommodate the more casual gamer.
As technology pushes forwards boundaries are slowly being broken down between systems. We saw the Bleemcast a few years back enabling the running of Playstation games on the Dreamcast, and the PC is able to run almost anything given the right emulation software. Consoles are able to emulate other consoles and new consoles are being announced that promise the ability to play PC games. The Xbox 2 is reported to have a model in planning that comes in a PC case and with the ability to run both PC software and Xbox software. Macs can emulate Windows software and vice-versa. We'll probably start seeing less of a distinction between consoles and PCs as the price of technology continues to drop and consoles continue to become more and more powerful and able to compete with the more expensive computers. Ideally we'll see a single platform come into prominence so that everything can be run without purchasing a copious number of different machines, although that does have a downside in that it can establish a monopoly for one particular company.
The technology price drop and increase in power has also lead to more powerful hand-held machines than before. Real games, not just simple toys are now available for the portable market. The advent of PDAs and mobile phones with the ability to play games raises awareness of portable gaming and new competitors are starting to get in on the field that was once primarily dominated by Nintendo's GameBoy. There is a new product, the gp32, that can run many different emulators and hence, many different system's games (including some PC games).
I can't say for sure what's going to happen but these are just a few ideas that I've had recently. Hopefully the games industry will continue to strive towards new heights with new and interesting game play, stories, characters and ideas. I'm looking forward to seeing what happens in the next few years.
About the Author
Daniel Punch M6.Net
Subscribe to:
Posts (Atom)
