On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote: > Hi José, > > the attached patch fixes incorrect swizzles in u_format.csv. There are > basically just 2 drivers which depend on the swizzles in this table: > llvmpipe and r300g. Since r300g started supporting pretty much every > texture format except SCALED ones, a few regressions have showed up. > This patch resolves all issues I had, especially with the SRGB formats > but I decided to clean it up all. git log: > > util: fix swizzles in the format table for 8-bits-per-channel > formats > > The 8-bits-per-channel formats having the same channel order had > completely > different swizzles, and at the same time, the same swizzles were > used for > completely different channel orders of 8bpc formats. > > This made the whole table self-contradicting, caused headaches, > and last > but not least, incorrent rendering for the drivers relying on > these swizzles. > > I hope I got it right. I didn't make a special distinction between the > array and arith layouts. All I did was to make sure that if I grep > e.g. A8R8G8B8, I'll get the same swizzles and not entirely different > ones.
Hi Marek, I'll need a bit more time to investigate this. One problem is that the interpretation of the swizzle varies with array vs arith. The ordering for array is the lowest significant word to the highest significant word (where word for 8bit formats is a byte), where for arith it goes from least significant bit to the highest significant bit. This is the same difference as array indexation and bit shifts. There is also the problem of byte order which affects the bit shift interpretation... I admit thet the current format description table is terribly underdocumented/confusing and likely broken in several ways. I wrote it to be able to code generate pixel format translation (which is wroking reasonably) and never expected people to use it for hardware drivers as well, although it is perfectly legitimate use. I have my own interpretation of these concepts, you and others hw driver writers have their own different interpretation. Furthermore in draw/translate/util modules there are some inconsistencies in these interpretations too. So I need to read the GL and DX10 specs very well, see how current drivers are using the descriptions, and come up with something that makes sense for everybody. So please hold on to your patch for a couple of days. I'd appreciate if the interested parties could take a good look to u_format.h comments, and summarize what they think the format semantics should be. Jose ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
