Brian Paul wrote:
Roland Scheidegger wrote:
here's a patch which mainly does 3 things: - convert sis, mach64, and radeon to spantmp2. The sis and mach64 drivers got a slight change, previously you could not read back alpha values (always 0xff) and I don't think there was a good reason for that?
IIRC, the mach64 doesn't support destination alpha planes. OpenGL requires that reads of absent alpha planes returns 1.0. I don't know
if the SiS chip is the same.
Are you sure? At least the driver handles things like GL_DST_ALPHA blend
factors, wouldn't you get awfully bogus results if it wouldn't support destination alpha planes in that case? It does not export BGRA visuals however for some reason. Note that r128 driver (which was converted to use spantmp2 by Ian and thus got that same change in behaviour reading back RGBA pixels already) does not export visuals with a alpha component neither (just BGR 888, if I read that right). SIS OTOH exports BGRA visuals.
Like I said, "IIRC". If you run the Mesa 'reflect' demo and hit 'a' you should see the contents of the alpha channel. The demo may need to be hacked to request GLUT_ALPHA in glutInitDisplayMode. But that'll show if you've got a functioning alpha channel. Maybe someone with a mach64 or sis can try that.
Does this look sane? Driver source code should get quite a bit smaller overall.
As long as you're looking at the span functions I should tell you that at some point in the future, work on the GL_EXT_framebuffer_object extension will likely require some changes in this area.
I'll elaborate on that in another email when I have things better sorted out. I'm doing initial implementation with the xlib renderer now.
But one thing that seems to be wrong in the r200 driver (for example)
(and probably all the other DRI drivers) is the fact that the r200SetBuffer() function ignores its <colorBuffer> parameter.
As it is now, the function ignores that parameter and always assumes that the span functions are going to be reading/writing to the context's current drawing buffer.
The glXMakeContextCurrent and glXMakeCurrentReadSGI functions specify
separate 'read' and 'draw' drawables. This allows you to do a glCopyPixels from one window to another, for example. This won't
work if the colorBuffer parameter of r200SetBuffer() is ignored.
In general, the span functions are relying too much on the GLcontext state, and not enough on the GLframebuffer state. The pointer to the start of the color/depth/stencil buffer, its width, height, pitch, etc. should be obtained via the GLframebuffer passed to r200SetBuffer.
To do that, I guess GLframebuffer would need to have a pointer back to the corresponding __DRIDrawablePrivate, since we have no way to contain one in the other.
Anyway, I wouldn't change anything right now. Let's wait until the GL_EXT_framebuffer_objects stuff has firmed up.
I do not think these changes should interfere with that however, since the code generated should not change at all, it's just unuglifying by moving macros around (except for those drivers which got converted to use spantmp2, but you'll need to make it work with that anyway if somehow that template won't be able to deal with these necessary changes).
I meant to say that you should go ahead with your changes now (as far as I'm concerned), and don't worry about the GL_EXT_renderbuffer_object stuff or the ignored GLframebuffer parameter for now. Sorry for not being clear.
-Brian
------------------------------------------------------- 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
