I was looking in this Gallium things and got a question on surface format. I think the format gallium ask to the driver should be restricted to type like rgb color, luminance, z buffer, stencil, ... and shouldn't explicitly ask for rgb888 or rgb with one float per color. The driver could then expose its capacity for each format type that in turn might be exposed either to higher api (gl) or/and through winsys. I believe all failover rendering use get/put_tile callback from surface then to access properly each surface.
I did see the comment in p_defines.h about s8z24 or others things like that and i believe we can work around this by having two surface attached to one buffer one exposing the stencil part while the other expose the z. And others things in future like vertex buffer in which we render might fit this scheme better than the current one. So to sum up format be two things: - a type (z, rgb, luminance, alpha, stencil, vertex, ...) - a set of properties (like r = 8bits signed or r = float 32, ...). Each driver advertise supported properties for each type. Hope this make sense :) Cheers, Jerome Glisse ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev