Dave Witbrodt wrote:
Anyway, I would like to report a bug on Mesa about OpenGL support not quite working on my Radeon HD 4850. I have read the "FreeDesktop Bugzilla User's Guide" and have created an account there. Before I report a bug, can you give me some advice?
1. The OpenGL corruption looks different on "radeon" versus "radeonhd". Should I provide screenshots of applications with OpenGL disabled (no corruption) and OpenGL enabled (with corruption)? If so, should I provide screenshots of corruption with both "radeon" and "radeonhd" (since it appears somewhat different)?
Sure.
2. I have made some fullscreen screenshots already, but my desktop is 1920x1200 and the resulting files were rather large: between 600KB and 3.5MB. Is there a rule about not posting attachments that are too large, or a limit on the size of attachments?
Not sure what the limits are off hand, but if you could just crop an area to show the corruption that would be fine.
3. Should I make an effort to identify bugs that might be related, or should I leave that to the developers? (I have already looked around, and haven't seen anything particularly similar to my problems, but my search was far from exhaustive.)
That's fine. We'll mark the bug as a duplicate if it ends up actually being one.
OK, I have to work right now, but when I get home I'll get to work on this. I know about the Intel guide on how to file a good bug report on freedesktop.org, so I'll collect the info recommended there before making the report.
Since sending you this message, I discovered that running those apps with OpenGL enabled spams dmesg/kern.log with errors like this:
[drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset
Some Googling revealed that you have fixed this in xf86-video-ati in October (commit 5f84636...). My Debian Sid version of "radeon" is 6.12.3 from early September. I cloned the git repository of xf86-video-ati, and reading 'git log' I see that recent commits are starting to depend on X server 1.7+, but I currently am running 1.6.5. Therefore, before filing the report, I want to bump my X server up and build the latest "radeon" to see what affect your bugfix has. If I'm still having a problem, then I head over to freedesktop.org for a new bug report.
Heh, never mind the bug report! Sometime between the release of radeon v6.12.3 and Nov. 23 the cause of my OpenGL corruption was fixed -- most likely the commit to which I referred above. First, I decided to upgrade to X server 1.7.0 from Debian's experimental distribution. Some ABI dependencies imposed by Debian's packaging team prevented me from using any DDX drivers provided before (with 1.6.5), so I had to install a nearly complete suite of development packages so I could build new DEBs for "radeon" and "radeonhd" that would not conflict with the 1.7.0 server. After building the two DDX drivers, I upgraded to Xorg 7.5 (with the 1.7.0 server). Restarting X, using "radeon" (not "radeonhd") gave me an almost perfect Xorg.0.log, encouraging results from 'xdpyinfo' and 'xvinfo', and my OpenGL test apps ('prboom' and 'dosbox') work better with OpenGL enabled than they do with it disabled! Thanks to Alex for the fix (commit 5f84636... in xf86-video-ati)! It's late, and I have to work tomorrow, but tomorrow night I will try "radeonhd" on X server 1.7.0. I expect that the OpenGL corruption will still happen with "radeonhd," unless someone has already ported the fix from "radeon". Next stop: kernel modesetting! Thanks again to all of the xf86-video-{ati,radeonhd} developers, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org