Triplebuffering

Reverend

Banned
In fullscreen mode, when is triplebuffering good or no good when AA is applied?

I ask because after a lot of emails back and forth amongst me, ATI and Epic about a certain 4xAA/6xAA UT2003 benchmark "oddity" on the 9700 Pro, I have found out the reason is due to triplebuffering.
 
Rev,
The only thing I can think of is that it's an "out of memory" problem due to requiring the extra space for the 3rd framebuffer combined with the higher res needed for AA <shrug>
 
I'd think any conditions that may force DIME/Execute due to cramped vmem space would result in triple buffering causing dramatic ill effects in performance.

One of the ATI guys at Rage3D explained that the 9700 Pro pre-allocates the same sample buffer space as a supersampling solution.

Given their calculations, at 1600x1200x32 with 6xAA, this consumed over ~115MB of vmem *without* textures, just frame/back/sample and z-buffers.

I can easily see "borderline" cases with excessive texture space needs crossing a threshold of forcing massive execute versus light execute by using AA and triple buffering, whereas disabling triple buffering might free up enough space to just clear the other side of the threshold.
 
For what it's worth UT2003 also seems to suffer from noticeable mouse lag when triplebuffering is enabled. Although my reducemouselag setting is set to false as well.
 
Sharkfood said:
Given their calculations, at 1600x1200x32 with 6xAA, this consumed over ~115MB of vmem *without* textures, just frame/back/sample and z-buffers.
Actually, it's about 109 MB (115,000,000 bytes). Still a lot of memory, though.
 
It seems like only yesterday when people laughed off 3d accelerators needing 128 megs of memory. When are those 256 meg cards coming? ;)
 
I wont even comment about how that makes my 16M 3dfx V3 cards seem... ::snicker::

--|BRiT|
 
BRiT said:
I wont even comment about how that makes my 16M 3dfx V3 cards seem... ::snicker::

--|BRiT|

Don't worry, V3's fill rate (restrict resolution) and texture size caps will make sure that 16MB won't go down without a fight! ;) :LOL:
 
Would the gigapixel antialiasing use extra memory in the buffers?
anyone knows when or if nvidia is gonna use it?
or maybe better techniques coming?
is coverage calculation gonna be possible soon?
 
malcolm said:
Would the gigapixel antialiasing use extra memory in the buffers?
anyone knows when or if nvidia is gonna use it?
or maybe better techniques coming?
is coverage calculation gonna be possible soon?

Well, nVidia has been using a very similar technique since the GeForce3, the primary differences being sample positioning and gamma-correct FSAA (both are related to edge/line AA quality). Since nVidia has so very little to go to match ATI's FSAA, it wouldn't be unwarranted to be disappointed if nVidia doesn't go a step further (In other words...there's absolutely no excuse for nVidia's NV30 to have FSAA < the R300's).
 
Bigus Dickus said:
Chalnoth said:
NV30 to have FSAA < the R300's).

I think you meant NV30's FSAA > R300's.
err no he means NV30's FSAA should be >= R300's FSAA

i.e. quite rightly there is no excuse for it to be less than R300's given the smallish differneces between R300 and NV25 MSAA implementation and the engineers nVidia have.
 
Not sure this fits within the original topic, but what the hey...! :)

Does MSAA fix polygon popping? Ie, the old example in a driving game where lamp posts far away seem to wink in and out of existence before they're close enough to always cover at least one pixel in width all the time?

Haven't actually tried to check this myself, but maybe it can differ between different implementations. Perhaps GF3/4 MSAA can't do it, but some other implementation could, what do I know? :)


*G*
 
Grall said:
Does MSAA fix polygon popping? Ie, the old example in a driving game where lamp posts far away seem to wink in and out of existence before they're close enough to always cover at least one pixel in width all the time?
It will depend, first of all, on a developer's implementation of LOD (how far into the distance before something appears and how soon after it appears before a user sees it) and then it will depend on the maximum number of AA samples.

It's a difficult question to answer :).
 
Grall said:
Not sure this fits within the original topic, but what the hey...! :)

Does MSAA fix polygon popping? Ie, the old example in a driving game where lamp posts far away seem to wink in and out of existence before they're close enough to always cover at least one pixel in width all the time?

Haven't actually tried to check this myself, but maybe it can differ between different implementations. Perhaps GF3/4 MSAA can't do it, but some other implementation could, what do I know? :)


*G*

Good old jittered RGSS (Voodoo4/5) fixed that up well :)
 
256MB late summer/early fall next year.

That would imply that the Nv30 does not have 256mb of ram.

Or that it ain't showin till the cows come home ;) ... but im sure its more likely the first case.
 
Randell said:
Bigus Dickus said:
Chalnoth said:
NV30 to have FSAA < the R300's).

I think you meant NV30's FSAA > R300's.
err no he means NV30's FSAA should be >= R300's FSAA

i.e. quite rightly there is no excuse for it to be less than R300's given the smallish differneces between R300 and NV25 MSAA implementation and the engineers nVidia have.

Having just come off a Ti4600 for the 9700, I wouldn't characterize the visual differences as "small." I made a habit with the 4600 of running with FSAA off (and anisotropic to 8x) simply because the image quality was so poor with FSAA compared to what I considered a standard--the V5 RGAA. 4x FSAA on the 4600 I found particularly bad in most applications, as I saw a lot of blurring--And Quincuxx was pretty uuugly...;)

But the 9700 is the first card to impress me with FSAA since the V5, and I find myself using it often these days, almost unconsciously. Looks great and doesn't kill performance, most of the time.
 
Back
Top