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=lnkkid=103432bid=230486dat=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=lnkkid3432bid#0486dat1642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
