Am Freitag, den 27.01.2006, 11:33 +0100 schrieb Michael Karcher: > Am Donnerstag, den 26.01.2006, 22:31 +0100 schrieb Michael Karcher: > > Am Donnerstag, den 26.01.2006, 14:05 -0700 schrieb Brian Paul: > > > I don't have a Savage card to test anything myself. Looks like the > > > driver's ColorMask code depends on the card model. Which card are you > > > using? > > As the subject says, it is a Savage IX built into a Thinkpad T20. I > > probably should add that I am using 16bpp, which makes bitmask errors > > possible. > I now tried other depths, which just showed another bunch of problems. > If I switch to 24bpp, I get really funny colors in 2D mode, they change > with the xgamma setting. I guess the gamma correction tables are messed > up. 3D acceleration produces very strange results (picture width > horizontally half of what it should be, distorted geometry and colors) > which give the impression that some part of hard- or software is > assuming 2 bytes per pixel instead of four. > Software fallback (as Felix mentioned) in the red/blue stereo case works > OK (except for the funny colors already seen in 2D), and looks the same > as with LIBGL_ALWAYS_INDIRECT, but of course it is slow.
If the color depth makes a difference then it could be related to the z-buffer depth or maybe color dithering. There is nothing you can do about the z-buffer depth (on Savage4 you could experiment with a floating-point z-buffer). But try disabling color dithering in DRIconf. Regards, Felix > > After that experience I tried 15bpp. In this case 2D looks quite OK. The > gradient in the window title of my sawfish theme looks a bit odd with > too much red mixed in some steps, but that might be an application bug. > 3D acceleration does not work correctly, as warning messages of libgl > already say "driver claims to not support visual 0x..". The output of 3D > acceleration looks like it is meant for 16bpp. Software fallback in the > red/blue-stereo case does *not* work correctly: The image width doubles, > and at some time the application crashes. It looks like rendering for > 32bpp, which might be OK. > > A final note to the 16bpp case: The performance of xmakemol and the > User-to-system CPU usage ratio seem to indicate the software fallback, > so the question remains: Why is the output wrong? > > Michael Karcher > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > > -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
