https://bugs.freedesktop.org/show_bug.cgi?id=82397
Priority: medium
Bug ID: 82397
Assignee: dri-devel(a)lists.freedesktop.org
Summary: some GLSL demo render badly on Radeon 7870
Severity: normal
Classification: Unclassified
OS: All
Reporter: nowaker(a)geozone.pl
Hardware: Other
Status: NEW
Version: 10.1
Component: Drivers/Gallium/radeonsi
Product: Mesa
The demo doesn't render correctly on Radeon 7870 (glamoregl+radeonsi) on Mesa
10.1. I didn't try Mesa 10.2 because of critical bug #65963, so others are
welcome to validate on Mesa 10.2.
Demo: http://glsl.heroku.com/e#18749.0
Rendered on my friend's blob:
http://x.rushbase.net/62726ab9e439bc355ce7a4846ea1cafd67a5b628/glsl.mp4
How it looks for me: http://upload.nowaker.net/nwkr/1407613451_blah.png
I will soon check on Mesa 10.2.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=82488
Priority: medium
Bug ID: 82488
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Error: couldn't get an RGB, Double-buffered visual
Severity: normal
Classification: Unclassified
OS: All
Reporter: 407883775(a)qq.com
Hardware: Other
Status: NEW
Version: 10.2
Component: Drivers/Gallium/radeonsi
Product: Mesa
My computer arch is sparc. The system is linux 64 bit
I am compiler Mesa(10.2.5) and kernel(3.10.0).
when i userd commond startx start X, but the glxgears it can not running .
message :
glxgears: Error: couldn't get an RGB, Double-buffered visual
glxinfo :
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=69196
Priority: medium
Bug ID: 69196
Assignee: dri-devel(a)lists.freedesktop.org
Summary: gpu lockup and full crash when starting some games in
wine
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: maxmusterm(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/DRI/R600
Product: Mesa
Created attachment 85587
--> https://bugs.freedesktop.org/attachment.cgi?id=85587&action=edit
kernel log from the crash
First of I searched the bugs and found some similar looking bugs but none which
stroke me as the same bug.
lspci tells me my graphics card is
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape
Verde XT [Radeon HD 7770 GHz Edition]
I always use everything mesa and kernel vanilla from git.
My kernel has the version 3.11.0-1-08716-g26b0332-dirty.The mesa checkout is 4
days old.
glxinfo tells me Mesa 9.3.0-devel (git-0f6fce1) (if this is relevant)
I tested it with hyperz enabled and disabled both time it failed the same way.
First the display turns dark (no signal) and then after being responsive for a
few seconds the pc crashes completly.
If I kill the process in time it doesn't die completly on me.
I don't know if this is of any relevance but the firmware for the card was
missing and I grabbed the file from here:
http://people.freedesktop.org/~agd5f/radeon_ucode/VERDE_smc.bin
I'll refrain from parsin anything specific from the kernel log since I don't
know which lines are relevant
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=81290
Priority: medium
Bug ID: 81290
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [radeonsi] DRI crash
Severity: normal
Classification: Unclassified
OS: All
Reporter: RalfPeter.Rohbeck(a)quantum.com
Hardware: Other
Status: NEW
Version: XOrg CVS
Component: DRM/Radeon
Product: DRI
Created attachment 102697
--> https://bugs.freedesktop.org/attachment.cgi?id=102697&action=edit
Xorg.0.log
I did a little torture testing with a fully updated Debian sid. This one
happened (I think) playing some random video from my disk with VLC but it might
also have been been caused by iceweasel with a couple of large images open.
xserver-xorg-core 2:1.15.99.904-1
libgl1-mesa-dri 10.2.3-1
vlc 2.1.4-1+b3
iceweasel 30.0-2
Sorry no symbols, I just installed them - will try to reproduce it with
symbols.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=79842
Priority: medium
Bug ID: 79842
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Performance drop since mesa 10.1.4
Severity: normal
Classification: Unclassified
OS: All
Reporter: kontakt(a)ib-guder.de
Hardware: Other
Status: NEW
Version: 10.1
Component: Drivers/Gallium/radeonsi
Product: Mesa
Created attachment 100755
--> https://bugs.freedesktop.org/attachment.cgi?id=100755&action=edit
The results from fumark benchmark
Hello.
I've noticed a performancedrop since mesa 10.1.4 (and also with 10.2.1 now). I
ran fumark_benchmark and unigine_valley. I append the results for fumark. I
don't know if it is kernel or mesa problem.
I use radeonsi.
Best regards!
Tom
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=32312
Summary: openvg "lion" demo freezes the system & lockup GPU
with r600g
Product: Mesa
Version: git
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: virtuousfox(a)gmail.com
in time of bug #30684 r600g were giving poor performance with "lion" demo
(about ~30 fps on my system) but not long ago i've noticed big, x10 time
speedup (up to ~350 fps). however, it was not for long: with
783e7caadf945f176cb297b8791769e2855fc9ef revision launching "lion" demo on my
system results in
1) video system freeze
2) 100% CPU time usage on all cores and total system freeze up if i not act
quickly and not kill demo process via ssh fast
if killed in time - all goes back to normal, in exception of
launching gles1gears demo right after which results in same behaviour.
however, repeated launch of gles1gears results in working demo but with some
artefacts.
third launch is all ok.
i'm pretty sure that regression was introduced in r600g in last 48 ~hours (same
revision but with r300g work ok) but i haven't done bisect.
--
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=90378
Bug ID: 90378
Summary: GPU lockups in Left 4 Dead 2
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: daniel(a)constexpr.org
QA Contact: dri-devel(a)lists.freedesktop.org
Created attachment 115653
--> https://bugs.freedesktop.org/attachment.cgi?id=115653&action=edit
dmesg output
While playing L4D2 today I got a lot of GPU lockups.
While the lockups seem to happen randomly, they are fairly easy to reproduce in
the third chapter (The Mall) of the Dead Center campaign. I recorded an
apitrace while encountering 3 lockups and there seem to be at least a couple of
lockups each time I retrace it:
http://constexpr.org/tmp/L4D2-radeonsi.trace.xz (507 MiB)
At least driver was able to successfully reset the GPU each time.
There also seem to be some infrequent rendering glitches.
Probably related to bug 89228, and possibly bug 90217, bug 90284 and/or bug
89954 (all reports of lockups with Source engine games).
GPU; Radeon HD 7950 (TAHITI)
Mesa 10.6.0-devel (git-3bdbc1e)
LLVM r236436
Linux 4.0.1-gentoo
The above logs and apitrace were recorded with unsafe-fp-math enbled (see bug
89069 comment 34) but the lockups also happen without it. I also noticed some
VM fault messages in dmesg while running L4D2 without unsafe-fp-math.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=88978
Bug ID: 88978
Summary: [bisected] [SI Scheduler] Graphical corruption in Dota
2
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: commendsarnex(a)gmail.com
QA Contact: dri-devel(a)lists.freedesktop.org
CC: tstellar(a)gmail.com
Hi guys. If I use LLVM git, I get these graphical glitches in Dota 2 native.
https://i.imgur.com/I4vyWFt.jpg
The bug has been bisected to LLVM: 51a3c27d6e0c66cc8d2d1da8e9205fec7b74ca5c
R600/SI: Define a schedule model and enable the generic machine scheduler
I'm using Mesa git, Kernel 3.18.5 and Linux Mint.
Thanks alot,
sarnex
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=90484
Bug ID: 90484
Summary: LLVM >=r237140 causes gpu lockups Spec Ops: The Line
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: arek.rusi(a)gmail.com
QA Contact: dri-devel(a)lists.freedesktop.org
Created attachment 115840
--> https://bugs.freedesktop.org/attachment.cgi?id=115840&action=edit
dmesg
I can't even start gameplay, gpu lockups a few seconds after intro in game
menu. cape verde
first bad combo:
llvm >=r237140 + mesa git
llvm r237139 (or 3.6) + mesa git works really good.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=83998
Priority: medium
Bug ID: 83998
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Oopses on R9270X using UVD since radeon/uvd: use
PIPE_USAGE_STAGING for msg&fb buffers
Severity: normal
Classification: Unclassified
OS: All
Reporter: adf.lists(a)gmail.com
Hardware: Other
Status: NEW
Version: git
Component: Drivers/Gallium/radeonsi
Product: Mesa
R9270X Getting rareish Oopses and once oomkiller since -
commit 6327b584155d040ae089e65fd6747186bdd9666b
Author: Christian König <christian.koenig(a)amd.com>
Date: Thu Sep 11 09:50:00 2014 +0200
radeon/uvd: use PIPE_USAGE_STAGING for msg&fb buffers
That better matches the actual userspace use case, the
kernel will force it to VRAM if the hardware requires it.
To trigger this I need to repeatedly start mplayer using uvd - it's takes some
time, I ended up making a script to do it for me while AFK.
I am 99% sure the above is it - I spent a day and a half trying on the commit
before (radeon/video: use the hw to initial clear the buffers) with no crash.
The Oopses don't mention radeon or uvd.
They will hit as soon as mplayer launches before it renders anything - screen
locked, no mouse cursor or vt switch but SysRq works, box is still up in some
ways for a while (one time I had music playing for 30s-1min after).
One time oomkiller put on its blindfold and ran around killing :-)
--
You are receiving this mail because:
You are the assignee for the bug.