https://bugs.freedesktop.org/show_bug.cgi?id=34708
Summary: running piglit on r600 causes gkrellm to lose text
color
Product: Mesa
Version: 7.10
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: hramrach(a)gmail.com
Created an attachment (id=43790)
--> (https://bugs.freedesktop.org/attachment.cgi?id=43790)
screenshot of part of the gkrellm window
After running some 3d apps (eg. piglit) parts of gkrellm lose text color.
Firefox does not seem affected, nor are terminals.
While taking the screenshot the Lock and Shoot buttons which were previously OK
lost color while they were redrawn.
As all the text that loses color is the value text (as opposed to the label
text) it looks like any newly drawn text is not colored (black).
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=30651
Summary: r600g: gl output in mplayer have no colors if used
with a fragment program with additional lookup and
bicubic B-spline filtering
Product: Mesa
Version: git
Platform: All
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: virtuousfox(a)gmail.com
when i try to play video in mplayer with option 'gl:yuv=4,lscale=1,cscale=1'
and r600g in use, it displays no colors. if it's 'gl:yuv=3', colors are ok.
'gl:yuv=5' seems also ok.
sorry, i haven't tested yuv=4 without 'lscale=1,cscale=1' and immediately
rebuilded mesa without gallium, so i don't know which of those to blame
actually. my bet is 'yuv=4' and "a fragment program with additional lookup".
by the way, what yuv and *scale options do you recommend for use with ATI/AMD
>=r600 cards in terms of performance and quality ?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=41051
Summary: Portal hard locks the machine on rv350.
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: oreaus(a)gmail.com
I recently installed Steam and subsequently the game Portal through wine and it
starts but after the loading screen, it hard locks the machine. The system
requirements for the game are low enough for this machine to handle. I'm not
really sure how to diagnose the problem but I've tested on 2.6.40.3-0.fc15.i686
and 2.6.38-11-generic with mesa master yielding same results. Using OpenGL
version string: 2.1 Mesa 7.12-devel (git-47b556f) with OpenGL renderer string:
Gallium 0.4 on ATI RV350.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=36596
Summary: Major 2D performance bottleneck (most noticeable with
compiz)
Product: Mesa
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: bluesloth600(a)gmail.com
Created an attachment (id=46072)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46072)
lspci -v
With compiz, making a new window or resizing a window makes the framerate drop
to 2 fps for about 5 or 6 seconds.
Running conky makes the frame rate that low most of the time, alternating with
brief moments of decent performance. With a more traditional window manager
(openbox), a lot of programs (including xterm) freeze briefly every time conky
redraws itself, so it seems like that particular problem is not entirely a Mesa
bug. Things run smoothly with the fbdev Xorg driver.
I tried compiz with the --no-fbo option once, and the framerate stayed at 2 fps
until I rebooted. Restarting X didn't help, I actually had to reboot.
With the classic Mesa drivers, compiz would sometimes take a long time to
render a few frames, but not nearly as often as it does now.
I've had this problem with the Debian Mesa packages since they switched to
gallium, and with git master (as of yesterday) built with and without
--enable-gallium-llvm.
I run Debian sid on a Dell Inspiron 1721 with an integrated Radeon X1270.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=35861
Summary: [r300g] Oilrush: whiter triangle between center of the
screen and horizon
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: minor
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: pavel.ondracka(a)email.cz
Created an attachment (id=45121)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45121)
terminal output
There is a strange triangle of whiter area and missing effects between screen
center and horizon in Oilrush.
I'm attaching terminal output, however I don't think there is anything
important, just a few of:
Mesa warning: glDraw[Range]Elements(start 130, end 877, count 1650, type
0x1403, indices=0x1c2)
end is out of bounds (max=876) Element Buffer 31 (size 3750)
This should probably be fixed in the application.
and
Mesa: User error: GL_INVALID_VALUE in glTexSubImage2D(xoffset+width)
OpenGL error: invalid value
However both of those errors are also present with llvmpipe which renders fine
(not 100% fine, but this bug is not present there).
RADEON_NOT_TCL=1 also solves this issue, where READEON_DEBUG=noopt has no
effect.
BTW you need to set MESA_EXTENSION_OVERRIDE="-GL_ARB_draw_instanced" when using
llvmpipe of software TCL otherwise you run into other troubles like:
GLShader::loadVertex(): error in
"core/shaders/default/meshes/vertex_base.shader" file
defines:
UNKNOWN,QUALITY_LOW,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_3D,USE_ALPHA_FADE,USE_ENVIRONMENT,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,HAS_ARB_DRAW_INSTANCED,BASE_AMBIENT_REFLECTION_CUBE,AMBIENT,PAINT,OPACITY,MULTIPLY_0
0:194(39): error: `gl_InstanceID' undeclared
0:194(42): error: Operands to arithmetic operators must be numeric
0:194(19): error: cannot construct `ivec3' from a non-numeric data type
0:194(58): error: Operands to arithmetic operators must be numeric
and almost no rendering at all.
My system
GPU:RV530
mesa: 9f013a8233197d4a0482661cb37cfeac1a61b804
Kernel: 2.6.38
Oilrush version: 0.61
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=34588
Summary: Screen corruption when running gtkperf on awesomewm
Product: Mesa
Version: git
Platform: Other
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/r300
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: jeff(a)deserettechnology.com
Recently, gtkperf will tear my whole screen apart in awesomewm 3.4.9 when it
gets to the drawing sections. I will try to take and attach a photo soon. I am
using cairo 1.10.2 with xcb enabled. I just compiled mesa, ati-dri, libgl,
xf86-ati from git today. This problem does *not* occur on a composited kwin
desktop on the same machine. Using a Macbook Pro 2,2 with Radeon Mobility
X1600. Using r300g.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.