Dieter Nützel wrote:
Am Samstag, 4. Dezember 2004 00:47 schrieb Roland Scheidegger:
Here's the new patch version (finally...).
Works so far on r200 here, too;-)
- when only stencil (or only z) buffer is cleared in a visual which
supports stencil and z, now a proper fallback clear is used (still
with z-buffer compression, but not with fast z-clear - I believe
this is a hardware limitation, or if it isn't a hardware limitation
I don't know how to do it...). The algorithm which decides if a
fallback clear is requried isn't very sophisticated though, so if
an app uses a visual with stencil but never uses the stencil it
will always use fallback clears. You can see that with QuakeIII, if
you do r_stencilbits 8 but leave cg_shadows at 1, quake3 will
never write to stencil nor clear it, which causes clear fallbacks.
I'm running with both and your fix [Bug 2010] but can't see any
problems with q3a.
Well, you should not SEE anything - the clear fallback should just cause
(and that indeed happens) a performance loss, but no visual anomalies.
The code required to avoid fallbacks in such cases wouldn't be that
complicated, but kludgy (it would not only be necessary to
remember if stencil has been written or not, but also the last the
last clear values had to be remembered and such). The fallback
clears fix DoomIII and NWN errors.
True for DoomIII, but who can switch the lights ON, finally...? ;-)
That is some weird texcoord problem. (I actually have a one-line
workaround for that, which breaks submitting texgen and non-texgen
coordinates at the same time more or less completely).
Your older version (with my little changes) was much more 'robust'
with multiple apps and/or 'zooming' a 3D app (e.g. with VTK).
'Zooming' a 3D VTK prog from the upper left corner into a bigger
window in the desktop middle show missing z/buffer clearing/redraw.
Was OK before.
Hmm, do you have a screenshot of that (or preferably more than one, I'm
interested what happens when you move the window from top-left to
top-right, bottom-left and bottom-right)?
Basically, this shouldn't be different than when you just changed the
clear mask with the old patch.
(Except when you're trying to use hier-z, then the results will be
different - I also believe that the new drm and dri hyperz patches are
not compatible to the old ones, you need to update both since I changed
some bit in the ioctl.)
Private z buffers might not help neither for that problem. It would
help for the z buffer compression issue (each application could
use it or not without causing problems), but fast z clear would
still not work correctly. I've not implemented anything though with
regards to multiple apps. glxgears and quake3 seemed to run quite
happily together though (on a rv250).
Should I play with the clearmask, again?
No, not unless you're serious about implementing a real hierarchical-z
solution.
[Bug 2010] New: depth and stencil readback are broken beyond x >
1023 Fix do not show any changes. zreaddraw is corrupted even with
screen redraw.
Do you mean with hyperz? That's to be expected (at least for now). That
bug 2010 depth readback problem is meant for cases without hyperz.
Have a look into SPECViewperf 7.1.2/8.0.1 _ugs_, too. Depth is mostly
broken there, too.
Works perfect (though slow as always...) for me (7.1). Screenshot?
Roland
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
