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

Reply via email to