On Thu, Dec 19, 2013 at 5:47 PM, Michel Dänzer <[email protected]> wrote:
> On Don, 2013-12-19 at 13:56 -0800, Mark Mueller wrote: > > Adjust MESA_FORMAT color component ordering to match API docs, driver > > specific formats (e.g. PIPE_FORMATs), > > Actually, there are a couple of examples of other format definitions > which match the Mesa formats before your change but no longer after it, > e.g. in the DRI and i915, nouveau and radeon driver code. > It's just not fair to hold the mesa formats to the varied conventions in the DRI driver code because they are all over the place across all the different drivers, past, present, and future (the confusion with MESA_FORMATs may be partly to blame). Moving the mesa formats closer to those of the API, instead of a nasty mix in-between, brings at least some clarity to the situation and the documentation burden can be left to the API specs - minus a few outliers. I'm pretty confident that this naming confusion is resulting in some unnecessary texture re-packing work due to _mesa_choose_tex_format returning less then optimal formats, though by name they look to be the best choice. My next series attempts to address that. > Changing the Mesa format definitions will be confusing for people > switching between branches with and without your change. > > Also, because these Mesa formats are defined as packed values, you're > essentially changing the notation from big endian (aka human readable) > to little endian. It's unfortunate that the packed PIPE_FORMATs are > named in little endian order, that's a concession we had to make when > adding them. > Are they all really big endian, currently it looks like a mix of who knows what. The main role the MESA_FORMATs are serving is to fortify the GLenums coming from the API, which are close to useless on their own. I don't think there is any question that there is a lack of convention and using the conventions already provided by the API offers the best fit for lots of reasons. > Overall, I'm afraid this change doesn't look very good at all to me. At > the very least though, you'd also have to change the order of component > sizes for formats such as MESA_FORMAT_BGRA2101010_UNORM or > MESA_FORMAT_BGRA1555_UNORM, otherwise they're just plain wrong. > > > > and actual use on common platforms. > > What does that mean? > I'm referring to PIPE_FORMAT, BRW_SURFACEFORMAT, RADEON_TXFORMAT, etc here. > > > > Remove comments giving MESA_FORMAT color packings, some of which are > > misleading. > > Which ones are misleading, and how? > Bottom line, if the MESA_FORMATs follow the API's convention, then the reader can go to the API for clarification and we don't have to maintain that in the code. There are some special cases which can be dealt with in the code. > > > > diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h > > index 94fc7a0..f224ed5 100644 > > --- a/src/mesa/main/formats.h > > +++ b/src/mesa/main/formats.h > > @@ -62,67 +62,68 @@ typedef enum > > MESA_FORMAT_NONE = 0, > > > > /** > > - * \name Basic hardware formats > > + * \name Basic API user space data formats > > All of Mesa is in user space. :) > > + * Please refer to API documentation for more information on format > > + * packing > > */ > > What API documentation? > opengl.org/wiki/Pixel_Transfer opengl.org/wiki/Image_Format http://msdn.microsoft.com/en-us/library/windows/desktop/bb172558(v=vs.85).aspx > Thanks for your input Michel. Do you still think this is a bad idea? Mark
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
