[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Jul 1 10:07:58 PDT 2011


https://bugs.freedesktop.org/show_bug.cgi?id=34495

--- Comment #28 from Micael Dias <kam1kaz3 at gmail.com> 2011-07-01 10:07:58 PDT ---
(In reply to comment #27)
> This is what I understood from GL_SELECT behavior : "Both the minimum and
> maximum window-coordinate z values of all vertices of the primitives that
> intersected the viewing volume"
> So by looping over buffer[] I'm trying to find the min/max z for the entry (at
> least that was the point, but maybe it's incorrectly done :-))

Yes but you're reading exacly the same buffer for each entry, therefore
returning the minZ and maxZ values of all the entries combined. That was my
interpretation of the code, but maybe I missed something.


> What happens if user changes something : it will not work reliably... Thanks to
> remind me of this problem which I almost forgot.
> Now the necessary state change should be limited :
> - GL_DEPTH_TEST : I don't understand why it doesn't work with it enabled, but
> it definitely not be changed

This got me thinking, and I think I know why. I believe currently minZ and maxZ
values returned will almost always be incorrect. This is because at the end of
a draw call without depth test you never know if the outputted pixels have the
minimum or maximum Z values. I think that in order to correctly do this we
would have to have 2 fbos. And we would render like this:

- enable depth test
- enable depth write
- select 1st fbo
--- set depth test function to "greater than"
--- render
- select 2nd fbo
--- set depth test function to "lesser than"
--- render
- loop through both fbos' buffers to determine minZ and maxZ

Unfortunately that last step will probably kill performance because we will
have to wait for the GPU, but there's no other way we can know which Z values
belong to which entries (unless we would allocate different pairs of FBOs for
each entry, which is obvisually unviable).
I still believe this would still be a lot faster than a software
implementation, specially with high poly meshes, which is where it matters the
most actually.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the dri-devel mailing list