Summary: | [r300g] textures flashing (disappearing) with GLSL | ||
---|---|---|---|
Product: | Mesa | Reporter: | Tomasz Czapiewski <xeros> |
Component: | Drivers/Gallium/r300 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | xeros |
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Photo of problem with blur in KDE 4.5.1
Photo of invisible textures in Nexuiz #1 Problem with invisible textures in Nexuiz #2 |
Description
Tomasz Czapiewski
2010-09-26 10:22:00 UTC
Created attachment 38971 [details]
Photo of problem with blur in KDE 4.5.1
Here the bottom panel does not show anything but the active window and time (everything else is invisible there) and window decoration is invisible, too.
Created attachment 38972 [details]
Photo of invisible textures in Nexuiz #1
Some textures look here like semi-transparent but they aren't, they change from visible to invisible... so quickly.
Created attachment 38973 [details]
Problem with invisible textures in Nexuiz #2
Maybe this will be usefull - After some searching for a way to improve FPS (by disabling vblank(?)), I've found that setting "vblank_mode=0" environment variable solved this issue (textures are not invisible anymore) in Nexuiz instead of disabling the limit of FPS to 30 or 60 FPS in game. Sorry for off-topic but is there a way to disable this FPS limit by vsync in games? I'd rather want to have 40-50 FPS rather than 30 if the game on my PC could not get full 60 FPS. "vblank_mode=0" works for disabling this limit in glxgears but not in Nexuiz (I've tried to force disable it by driconf and in game, too). The Nexuiz issue looks like bug 28341, but that was in r300c and fixed a while ago... I wonder if somehow you might be using libGL.so.1 / r300_dri.so binaries different from the ones you think, or if they might be built incorrectly. (In reply to comment #5) > The Nexuiz issue looks like bug 28341, but that was in r300c and fixed a while > ago... I wonder if somehow you might be using libGL.so.1 / r300_dri.so binaries > different from the ones you think, or if they might be built incorrectly. I'm not sure how the drivers and mesa were built (it's ppa:xorg-edgers/radeon: https://edge.launchpad.net/~xorg-edgers/+archive/radeon for Ubuntu 10.04, but I used it on Kubuntu 10.10 and both mesa and dri have been upgraded) and I'm almost sure I'm using r300g, not r300c (glxinfo output: "OpenGL renderer string: Gallium 0.4 on RV350"). I haven't seen the picture of the problem in bug 28341, but I don't have "*ERROR* Invalid command stream !" error or any other related errors in dmesg. I've tried different vblank_mode settings and with set to 0 or 1 the problem is gone but after setting it to more than 1 or without any vblank_mode setting the problem is still there on Mesa 7.10.0~git20100927+gallium+r300.029c099b-0ubuntu0tormod. What can I do more to get more information to help track this bug? As I've said before, there's no error in dmesg or other logs for this issue. The problem has been fixed by installing yesterday's xorg-edgers/radeon ppa packages for Ubuntu 10.10 Maverick. |
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.