Matthias Hopf wrote:
On Nov 24, 09 01:47:13 -0500, Dave Witbrodt wrote:
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
radeonhd shouldn't be affected from that, as we never stored more than the mapped memory in any structure.
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".
If you still see corruptions, it must be a different source from what I read in the code.
Matthias
OK, I'm home from work and I don't have to go back until Monday! First thing I tried when I got home was to copy my working "radeonhd" config to xorg.conf, restart X, and run the apps I'm using to test OpenGL. With OpenGL enabled, 'prboom' runs perfectly with "radeon" but has *massive* screen corruption with "radeonhd" (along with spamming dmesg and kern.log with [drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset This was the same behavior I experienced with "radeon" 6.12.3, and the same log-spam error messages are described in a bug from October on the fdo bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24301 I should point out that the corruption shown in the PNG images attached to that bug report are quite mild compared to what I get. However, I guessed that the difference had more to do with how the applications were written -- the extent to which their code hits the bug. (I have some very large, 1920x1200, screenshots if anyone wants to see them; I can easily crop them -- as recommended by Alex Deucher if I had created my own bugzilla report -- to save bandwidth, since they range from 600KB to 4.5MB in their current form.) I assumed that the fix provided by Alex for #24301 (commit 5f84636...) was the commit that caused "radeon" to work correctly with OpenGL for me. However, I do not know that for a fact... and could only determine which commit, or combination of commits, fixed "radeon" for me by doing a 'git bisect' between 6.12.3 and commit 3a1a8b7 on Nov. 23. To be honest, I had planned to move on to KMS once I had prepared a working config for "radeon". As with my previous efforts to build upstream versions of radeonhd, libdrm, and mesa, I want to get to KMS by building DEBs -- and this has been difficult for me since I am not a developer or package maintainer. These days off for the holiday in the US were my big chance to align the entrails and try out KMS. However, if it will help the "radeonhd" team, I am willing to bisect "radeon" to identify the exact commit(s) that give me working OpenGL on my RV770 card. Matthias: above you assert that "radeonhd shouldn't be affected from that" -- and maybe it *shouldn't* be -- but I can tell you that it *is* on my hardware, and I have logs full of those error messages even though I am running "radeonhd" instead of "radeon" at the moment. How would you like me to proceed? Shall I: - file a bug report on radeonhd? - bisect "radeon" until we know the specific commit? - test patches from radeonhd developers? I am willing to do any or all of these things, and anything else anyone can think of, to help make radeonhd better. Just let me know. With much appreciation for your efforts, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org