Hi, On Monday 30 May 2005 08:51, Vladimir Dergachev wrote: > On Mon, 30 May 2005, Bernhard Rosenkraenzer wrote: > > > Hi, > > I've just tried out the r300 driver - works remarkably well for "untested and > > broken" code. > > :)) > > > > > I've run into 2 bugs though: > > It doesn't work well if the display uses 16 bpp (24 bpp works perfectly) -- 3D > > in 16 bpp is pretty badly misrendered (sample attached; 2D works well w/ r300 > > DRI even at 16 bpp) -- mixed with a random section of the rest of the screen, > > wrong colors, and drawn way too large (but close enough to the expected > > output to recognize it). > > I don't think we ever focused on getting 16bpp right - having 32bpp > working is fun enough :) Also, all of r300 and later cards have more than > enough RAM for 32bpp modes. > > That said, it is probably just a matter of making sure some constants are > set properly (like colorbuffer parameters), I don't think anything else in > the driver is tied to that.
If fglrx supports 16 bits (seriously, I've never tried that - who wants 16 bits anyway ;)), it's a matter of using glxtest to figure out the necessary color buffer setup code. Some other constants may be different, but it's unlikely. In addition to that, you will have to change radeon_span.c (for software fallbacks, as wall as Read/DrawPixels functionality) accordingly, as well as probably some context creation related stuff. Also, you might want to look into the code that selects texture formats. It probably doesn't make too much sense to select a 32 bit texture format at a 16 bit screen resolution unless the user explicitly requests it. cu, Nicolai
pgpzGHEIXlh44.pgp
Description: PGP signature
