I have a PowerBook G4 with an RV350 [Mobility Radeon 9600 M10] graphics card. For quite some time now I am seeing rendering issues in OpenGL using application. Attaching a screenshot of neverball when it is started. This is a debian testing machine with the following package versions: xserver-xorg 1:7.5+3 xserver-xorg-video-radeon 1:6.12.4-3 libdrm-radeon1 2.4.17-1 I am happy to provide more information if neccessary.
Created attachment 33196 [details] neverball on the start screen after running a bit
What version of mesa are you using?
Mesa is at version 7.6.1 it seems. (I did not explicitly mention it, but it works fine without DRI.) libgl1-mesa-dri 7.6.1-1
Can you try if the problem persists with libgl1-mesa-dri 7.7-3 from experimental?
Unfortunately upgrading mesa-dri to 7.7-3 from experimental does not make any difference.
Okay, thanks for testing it. The screenshot looks like maybe the vertex data has the wrong byte order. We're setting the R300_VC_32BIT_SWAP bit in the R300_VAP_CNTL_STATUS register to have the GPU convert the big endian data from the CPU. However, that bit is not effective if the data is read from VRAM. Dave, is it possible that since radeon-rewrite vertex buffers may end up in VRAM without KMS?
If this helps at all, I can reproduce the problem. glxgears seems to run properly. The games "crack-attack" and "tomatoes" work properly, but occasionally have some polygons that are rendered improperly as with the neverball screen shots already provided. I suspect that the complexity of the scene being rendered plays some part.
IIRC I was using the post radeon-rewrite driver without KMS for a while on my PowerBook, and I don't remember issues like this. So with some luck, this is a regression between the radeon-rewrite merge (commit 7f223ff89172069dbad987f592aea2a8ba16355f) and 7.6.1 which could be bisected. BTW, can you guys attach your Xorg.0.log files?
I'm using kernel 2.6.33, libdrm-2.4.16 and not using KMS, but if you'd like I can try that as well. Bisected, and came up with this as the problem commit: 5fb5ea97f4439184f03075f57fa1fda56caf51b4 is the first bad commit commit 5fb5ea97f4439184f03075f57fa1fda56caf51b4 Author: Maciej Cencora <m.cencora@gmail.com> Date: Sat Jul 11 20:40:51 2009 +0200 r300: use VBOs for vertex attributes :040000 040000 a1563d1d248860e6feb264e5f8a2b97e618a31401538bf6175a6ca180af150086a5b99847a567436 M src If you'd still like my Xorg log, please let me know.
(In reply to comment #9) > If you'd still like my Xorg log, please let me know. Yes please.
Created attachment 33889 [details] X log, after startup and some usage including sleep/wake I'm also seeing messages like: Failed to free bo[(address)] at 00008000 ret = Operation not permitted I'm not sure if it's related, but I figured it was worth mentioning since the problem appears to lie with buffer objects.
(In reply to comment #11) > Failed to free bo[(address)] at 00008000 > ret = Operation not permitted > > I'm not sure if it's related, but I figured it was worth mentioning since the > problem appears to lie with buffer objects. It might be related; looks like something may be going wrong related to the fake buffer object handling in the Mesa driver or even in the kernel.
Is this still a problem?
(In reply to comment #13) > Is this still a problem? I'm having this issue with an rv350 trying to run sauerbraten with mesa 7.7.1-5 with a 1.67ghz g4 powerbook Anyone have a solution?
*** Bug 51594 has been marked as a duplicate of this bug. ***
The classic r300 driver has been abandoned long ago. It was replaced by the Gallium driver r300g. If you have issues with r300g please file a new bug report with component Drivers/Gallium/r300 Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.