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.
