From: Bernhard R. <be...@ar...> - 2005-05-29 22:38:18
Attachments:
glxgears.png
|
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). The 2nd bug is that tuxkart (http://tuxkart.sf.net/) segfaults when starting a game -- apparently the driver is returning a wrong value (or NULL pointer?) somewhere. The game works on r200 and i855; didn't have the time to do a lot of debugging yet. Any ideas? Thanks, bero |
From: Vladimir D. <vo...@mi...> - 2005-05-30 06:52:10
|
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. > > The 2nd bug is that tuxkart (http://tuxkart.sf.net/) segfaults when starting a > game -- apparently the driver is returning a wrong value (or NULL pointer?) > somewhere. The game works on r200 and i855; didn't have the time to do a lot > of debugging yet. Works fine here - try latest R300 CVS and latest Mesa. I am not playing it fullscreen if this matters any.. best Vladimir Dergachev > > Any ideas? > > Thanks, > bero > |
From: Nicolai H. <pre...@gm...> - 2005-05-30 16:26:54
|
Hi, On Monday 30 May 2005 08:51, Vladimir Dergachev wrote: > On Mon, 30 May 2005, Bernhard Rosenkraenzer wrote: >=20 > > Hi, > > I've just tried out the r300 driver - works remarkably well for=20 "untested and > > broken" code. >=20 > :)) >=20 > > > > I've run into 2 bugs though: > > It doesn't work well if the display uses 16 bpp (24 bpp works perfectly= )=20 =2D- 3D > > in 16 bpp is pretty badly misrendered (sample attached; 2D works well w= /=20 r300 > > DRI even at 16 bpp) -- mixed with a random section of the rest of the=20 screen, > > wrong colors, and drawn way too large (but close enough to the expected > > output to recognize it). >=20 > I don't think we ever focused on getting 16bpp right - having 32bpp=20 > working is fun enough :) Also, all of r300 and later cards have more than= =20 > enough RAM for 32bpp modes. >=20 > That said, it is probably just a matter of making sure some constants are= =20 > set properly (like colorbuffer parameters), I don't think anything else i= n=20 > the driver is tied to that. If fglrx supports 16 bits (seriously, I've never tried that - who wants 16= =20 bits anyway ;)), it's a matter of using glxtest to figure out the necessary= =20 color buffer setup code. Some other constants may be different, but it's=20 unlikely. In addition to that, you will have to change radeon_span.c (for software=20 fallbacks, as wall as Read/DrawPixels functionality) accordingly, as well=20 as probably some context creation related stuff. Also, you might want to look into the code that selects texture formats. It= =20 probably doesn't make too much sense to select a 32 bit texture format at a= =20 16 bit screen resolution unless the user explicitly requests it. cu, Nicolai |
From: Keith W. <ke...@tu...> - 2005-05-31 12:22:53
|
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 16bpp isn't supported, the DDX and/or r300 client driver should be modified not to try, and just fall back to indirect rendering. Keith |
From: Vladimir D. <vo...@mi...> - 2005-06-01 00:44:33
|
>> 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 16bpp isn't supported, the DDX and/or r300 client driver should be > modified not to try, and just fall back to indirect rendering. It think it would be better to put one of the WARN_ONCE messages about the fact that 16bpp is broken and needs to be fixed. Things that are broken and easy to fix are best exposed. best Vladimir Dergachev > > Keith > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |