Keith Whitwell wrote: > 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 >
What i was thinking is really somethings like the comment in p_defines.h ie seperate float/int/uint ... from the format. I was just concerned by the fact that the enum might grow pretty fast if we have to add one value for each possible format(rgb888,rgb444,rgb565,rgbdfloat32float32float32, ...) So my main concern was finding a sensible way to encode format and i wanted to be sure this was in your mind too :) If you choose to stick with large enum it's fine with me, anyway i think we can't avoid lengthy list of format. Oh in my scheme i did talk about stencil, color, z, ... but wasn't restricting to this, what i was thinking is to add as many type as you want and then each type would have its particular set of properties (ie rgb type would have r,g & b properties where each can be int8,uint8,int5, float32,float64, ...) so it simply was a proposition to split the enum. One things that made me think to this is when through winsys you tweak some parameters to force 16bits rendering. For instance the gallium ask for a RGB888, the allocator go through winsys say which tell gallium that it successfully allocated RGB888 but in fact it did allocate RGB565 and just plug correct tile get/put callback (or have a private format description) this way you can trick application to render the way you want (ie you can degrade precision). By the way in struct pipe_surface you define format a 5bits field which isn't enough to hold all current enum values of format... Oh and in others struct it's a 8bit field or an unsigned, but as i didn't deeply looked to the code this might just be another format not related at all with the one we are talking here. Maybe it's safer to use unsigned everywhere for format :) So in the end i think i didn't explained properly what i did have in mind. Hope now it's a bit more clear but anyway i am sure you will come with a better scheme (if you feel that's worth it) to encode orthogonal format. 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
