Jerome Glisse wrote: > 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 think what we've got is more or less equivalent (though you should be forgiven if you don't see this, as it isn't finished!). Basically the names of all interesting formats are defined as enums, and the state tracker can query the drivers regarding their capacity to operate on each format. In particular the driver should be able to state whether it can use a particular format as a texture, render target, or scanout buffer. There may be other interesting usages yet to be determined. > I believe all failover rendering use get/put_tile > callback from surface then to access properly each surface. Yes, this is my feeling also -- all the read/write quad stuff should go away and we just talk about tiles. This should be pretty simple to get done. The slight wrinkle is that we need to talk about two types of tiles, the current float32/chan, but also an uint8/chan (ie rgba8888), because logicop is undefined for floating point formats... Then you start to think about Z/Stencil and maybe there is a third type of tile required. But in general, yes tiles are the future, the quad interface to the surfaces is probably temporary and will likely go away soon. > 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 :) I think the world is moving towards a very orthogonal set of surface types, and there are only a few warts left (yuv, z/stencil, etc). It may make sense to treat the wierd cases specially. I'm concerned that your scheme above only really deals well with the sensible surfaces, and that it may be difficult for the state tracker to tell the driver what exact properties it wants the surface to have. Also I'd like to see the HW driver component be as dumb as possible, ie behave pretty much like hardware behaves. So talking about surface formats as enum values fits that model fairly well. We need some sort of query mechanism to figure out what surfaces are supported on each driver, but I think it should be as simple and unambiguous as possible. If we had a sensible way to encode the orthogonal formats without the huge explosion of enums in p_defines.h, and a set of hand-crafted enums for special cases, would that address your concerns? Is there something particular that you aren't able to achieve with the current model? Keith ------------------------------------------------------------------------- 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
