https://bugs.freedesktop.org/show_bug.cgi?id=66961
Priority: medium
Bug ID: 66961
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Kernel BUG/Oops during radeon gpu stall
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: knut.tidemann(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 82479
--> https://bugs.freedesktop.org/attachment.cgi?id=82479&action=edit
dmesg output
I've noticed a kernel BUG/Oops during a GPU stall when playing Legend of
Grimrock (closed source).
The oops causes X to become a defunct process with no entires in the Xorg.log
file. The screen goes into standby mode and the only way to solve this is to
reboot the computer. The machine is responsive via ssh and I've attached my
dmesg output after the oops.
I have not played this game with another kernel, so I don't know if it's new or
not.
I have a Radeon HD 4850, on an Intel Core2Duo with 8GB of ram.
Running 'latest' git (gb616d01).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66920
Priority: medium
Bug ID: 66920
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [llvm backend] flashing textures, no lights in car ,
no water on GTA IV
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: son_of_the_osiris(a)interia.pl
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
I just tried sb backend with GTA IV on wine and must say that it works better
than llvm. With llvm I have black rectangle instead of car lights and same with
water. Also I seen some flashing textures.When enable R600_DEBUG-sb,nollvm game
run little faster and without graphics problem.
Kernel 3.10
wine 1.6rc5
mesa - git
compiled with :
--prefix=/usr \
--sysconfdir=/etc \
--with-dri-driverdir=/usr/lib/xorg/modules/dri \
--with-gallium-drivers=r600 \
--with-dri-drivers= \
--with-llvm-shared-libs \
--enable-gallium-llvm \
--enable-r600-llvm-compiler \
--enable-xvmc \
--enable-egl \
--enable-gallium-egl \
--with-egl-platforms=x11,drm,wayland \
--enable-shared-glapi \
--enable-gbm \
--enable-glx-tls \
--enable-opencl \
--disable-debug \
--disable-osmesa \
--enable-gles1 \
--enable-gles2 \
--enable-texture-float \
--disable-xa \
--enable-vdpau \
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66883
Priority: medium
Bug ID: 66883
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [r600 llvm backend] Assert with 32-bit lightsmark, TF2
when shader dump is enabled
Severity: normal
Classification: Unclassified
OS: All
Reporter: ptpzz(a)yandex.ru
Hardware: Other
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
I have asserts in the middle of shader dump in llvm backend with 32-bit Team
Fortress 2 and Lightsmark, R600_DEBUG=ps,vs. Here is message with Lightsmark:
...
ALU_CLAUSE 8; dbg:backend: DebugLoc.cpp:27: llvm::MDNode*
llvm::DebugLoc::getScope(const llvm::LLVMContext&) const: Assertion
`unsigned(ScopeIdx) <= Ctx.pImpl->ScopeRecords.size() && "Invalid ScopeIdx!"'
failed.
TF2 message:
...
ALU_CLAUSE 32; dbg:hl2_linux: DebugLoc.cpp:33: llvm::MDNode*
llvm::DebugLoc::getScope(const llvm::LLVMContext&) const: Assertion
`unsigned(-ScopeIdx) <= Ctx.pImpl->ScopeInlinedAtRecords.size() && "Invalid
ScopeIdx"' failed.
It seems in both cases it happens on ALU clause start in the dump.
So far I can't reproduce this issue with 64-bit Lightsmark/mesa/llvm.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66738
GitLab Migration User <gitlab-migration(a)fdo.invalid> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |MOVED
--- Comment #16 from GitLab Migration User <gitlab-migration(a)fdo.invalid> ---
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.
You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/448.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66731
Priority: medium
Bug ID: 66731
Assignee: dri-devel(a)lists.freedesktop.org
Summary: texture issues in xonotic with llvm+sb and offset
mapping
Severity: minor
Classification: Unclassified
OS: Linux (All)
Reporter: stefano.teso(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
To reproduce, use:
- xonotic 0.7.0 at lowest detail, with only offset mapping turned on.
- r600g from git, with SB backend and LLVM both turned on. Turning off either
makes the bug disappear (although there are other issues, rensambling z
fighting, when only llvm is enabled; not sure if they are related to offset
mapping, I'll check later.)
The issue is clearly visible by running any of the demos that come with
xonotic. FWIW, other apps (glxgears, gnome-shell, etc.) work just fine.
$gitgl glxinfo | grep str
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CEDAR
OpenGL version string: 2.1 Mesa 9.2.0-devel (git-2923685)
OpenGL shading language version string: 1.30
$ llvm-config --version
3.3
Tested with both stock 3.10 kernel from arch linux and the recent dpm-wip5
branch.
Nothing suspicious in dmesg.
May be related to #50230, which was closed as fixed.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66632
Priority: medium
Bug ID: 66632
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Very low FPS when video memory is full (GART & ram <->
vram swapping)
Severity: major
Classification: Unclassified
OS: Linux (All)
Reporter: sonichedgehog_hyperblast00(a)yahoo.com
Hardware: All
Status: NEW
Version: 7.0
Component: Drivers/DRI/Radeon
Product: Mesa
Although I heard this issue was discussed, I couldn't find other bug reports
and wanted to post my observations on the matter. At this point it's the only
reason why I'm sticking with fglrx and can't switch to Radeon, and so far
couldn't find a workaround either.
Although Radeon and fglrx seem to run games as fast when no bugs occur, Radeon
has a major problem. If video memory is filled and textures have to be stored
on system memory, FPS drops unusably low. This can be noticed when a program
uses high quality content such as a lot of high resolution textures, enough to
fill up the video memory.
The best and only test case I know of (also the reason this problem affects me)
is the project Xonotic. When ran from the GIT repository, it has a lot of
high-res textures in original format (some as large as 2048px). Even when
texture compression is enabled, they quickly fill up my 1GB of video ram.
Therefore, when looking in certain areas of a map, FPS decreases enormously
(down to 3 FPS).
I ran several tests in the past and tried further debugging this today on IRC.
As other users pointed out, the constant swapping of items between the RAM and
VRAM is the most likely cause of the problem. A better GART formula is
apparently needed in order to swap only when necessary and not all the time.
Someone posted a log based on their tests:
http://bpaste.net/raw/lhJKFAYFyl0DNOMr9hwc/ At least one more user could
replicate the exact behavior I'm getting, and confirmed Xonotic is unplayable
when full-res textures are used and a map loads a lot of them. I was also
linked a patch, which was said to fix the issue although it wasn't accepted
yet. In case it's of any relevance,
http://people.freedesktop.org/~glisse/0001-drm-radeon-keep-original-user-re…
I heard a correct formula on when to trigger VRAM <-> RAM swapping is harder to
find, so I understand why this bug exists. Since it's a major issue and keeps
some engines from working when they could, it would be appreciated if even a
simple solution could be added in the meantime. Such as disabling swapping
altogether (what was placed in vram stays in vram and what's in gart stays in
gart) or only triggering swapping after a longer amount of time rather than
each frame (eg: 30 or 60 seconds).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66349
Priority: medium
Bug ID: 66349
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Using SB shader optimization caused segfault in
Serious Sam 3: BFE
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: thomas.lindroth(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 81666
--> https://bugs.freedesktop.org/attachment.cgi?id=81666&action=edit
dmesg, xorg.log
When using R600_DEBUG=sb Serious Sam 3 will segfault in mesa during the intro.
Running without sb works. I'm using git mesa, libdrm, drm-next and
xf86-video-ati-7.1.0. Here is the backtrace.
Program received signal SIGSEGV, Segmentation fault.
0xf385b151 in r600_sb::regbits::clear (this=0xffe4b57c, index=4293178748) at
sb/sb_ra_init.cpp:131
131 sb/sb_ra_init.cpp: No such file or directory.
(gdb) bt
#0 0xf385b151 in r600_sb::regbits::clear (this=0xffe4b57c, index=4293178748)
at sb/sb_ra_init.cpp:131
#1 0xf385b25b in r600_sb::regbits::from_val_set (this=0xffe4b57c, sh=...,
vs=...) at sb/sb_ra_init.cpp:117
#2 0xf385bdaa in regbits (vs=..., sh=..., this=0xffe4b57c) at
sb/sb_ra_init.cpp:62
#3 r600_sb::ra_init::color (this=0xffe4bb18, v=0x15c62168) at
sb/sb_ra_init.cpp:471
#4 0xf385bf81 in r600_sb::ra_init::process_op (this=0xffe4bb18, n=0x15ca7948)
at sb/sb_ra_init.cpp:344
#5 0xf385bfdf in r600_sb::ra_init::ra_node (this=0xffe4bb18, c=0x15cba670) at
sb/sb_ra_init.cpp:294
#6 0xf385bff7 in r600_sb::ra_init::ra_node (this=0xffe4bb18, c=0x15cba608) at
sb/sb_ra_init.cpp:297
#7 0xf385bff7 in r600_sb::ra_init::ra_node (this=0xffe4bb18, c=0x15c8a4e8) at
sb/sb_ra_init.cpp:297
#8 0xf385c03d in r600_sb::ra_init::run (this=0xffe4bb18) at
sb/sb_ra_init.cpp:285
#9 0xf3847450 in r600_sb_bytecode_process (rctx=0xa60a300, bc=0x15c6c9f4,
pshader=0x15c6c9f0, dump_bytecode=0, optimize=2097152)
at sb/sb_core.cpp:220
#10 0xf38209f8 in r600_pipe_shader_create (ctx=0xa60a300, shader=0x15c6c9e8,
key=...) at r600_shader.c:179
#11 0xf38335b1 in r600_shader_select (ctx=0xa60a300, sel=<optimized out>,
dirty=0x0) at r600_state_common.c:750
#12 0xf38337ea in r600_create_shader_state (ctx=0xa60a300, state=<optimized
out>, pipe_shader_type=1) at r600_state_common.c:797
#13 0xf3833834 in r600_create_ps_state (ctx=0xa60a300, state=0x15c43c28) at
r600_state_common.c:807
#14 0xf365f051 in st_translate_fragment_program (st=0xa73f748, stfp=0x15c7a060,
key=0xffe4c648) at ../../src/mesa/state_tracker/st_program.c:768
#15 0xf365fd20 in st_get_fp_variant (st=0xa73f748, stfp=0x15c7a060,
key=0xffe4c648) at ../../src/mesa/state_tracker/st_program.c:805
#16 0xf3626b85 in update_fp (st=0xa73f748) at
../../src/mesa/state_tracker/st_atom_shader.c:92
#17 0xf3623912 in st_validate_state (st=0xa73f748) at
../../src/mesa/state_tracker/st_atom.c:221
#18 0xf36376fc in st_draw_vbo (ctx=0xa6f8b28, prims=0xffe4c7d8, nr_prims=1,
ib=0xffe4c7f0, index_bounds_valid=1 '\001', min_index=0,
max_index=3, tfb_vertcount=0x0) at
../../src/mesa/state_tracker/st_draw.c:210
#19 0xf360da07 in vbo_handle_primitive_restart (ctx=<optimized out>,
prim=<optimized out>, nr_prims=1, ib=0xffe4c7f0,
index_bounds_valid=1 '\001', min_index=0, max_index=3) at
../../src/mesa/vbo/vbo_exec_array.c:549
#20 0xf360e8ec in vbo_validated_drawrangeelements (ctx=0xa6f8b28, mode=4,
index_bounds_valid=1 '\001', start=0, end=3, count=6, type=5123,
indices=0x0, basevertex=0, numInstances=1, baseInstance=0) at
../../src/mesa/vbo/vbo_exec_array.c:968
#21 0xf360eaa7 in vbo_exec_DrawRangeElementsBaseVertex (mode=4, start=0, end=3,
count=6, type=5123, indices=0x0, basevertex=0)
at ../../src/mesa/vbo/vbo_exec_array.c:1076
#22 0xf360eaeb in vbo_exec_DrawRangeElements (mode=4, start=0, end=3, count=6,
type=5123, indices=0x0)
at ../../src/mesa/vbo/vbo_exec_array.c:1096
#23 0x08f0bf3d in ?? ()
#24 0x08a9f8b1 in ?? ()
#25 0x089a8459 in ?? ()
#26 0x089a188e in ?? ()
#27 0x08aadc5a in ?? ()
#28 0x08a9fb0a in ?? ()
#29 0x08a9fd56 in ?? ()
#30 0x08c8e65f in ?? ()
#31 0x08c9284a in ?? ()
#32 0x08b52309 in ?? ()
#33 0x08b66e96 in ?? ()
#34 0x08b92394 in ?? ()
---Type <return> to continue, or q <return> to quit---
#35 0x08b498de in ?? ()
#36 0x08b49a86 in ?? ()
#37 0x08b49be1 in ?? ()
#38 0x08d89685 in ?? ()
#39 0x08b4a23d in ?? ()
#40 0x08b45e77 in ?? ()
#41 0x08b47332 in ?? ()
#42 0x0888e7fa in ?? ()
#43 0x0888867e in ?? ()
#44 0x083e9df5 in ?? ()
#45 0x083ea964 in ?? ()
#46 0x0853f143 in ?? ()
#47 0x089143d0 in ?? ()
#48 0x083a017f in ?? ()
#49 0x083a0293 in ?? ()
#50 0x08a06046 in ?? ()
#51 0x08d85243 in ?? ()
#52 0x08d85678 in ?? ()
#53 0x0804f54b in ?? ()
#54 0xf755a943 in __libc_start_main (main=0x804f520, argc=1, ubp_av=0xffe4e114,
init=0x8f63330, fini=0x8f633a0, rtld_fini=0xf77964e0 <_dl_fini>,
stack_end=0xffe4e10c) at libc-start.c:226
#55 0x0838e785 in ?? ()
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66067
Priority: medium
Bug ID: 66067
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Trine 2 color problems on Radeon HD 6770 (Juniper)
Severity: normal
Classification: Unclassified
OS: All
Reporter: nmiell(a)gmail.com
Hardware: Other
Status: NEW
Version: git
Component: Drivers/DRI/R600
Product: Mesa
Created attachment 81244
--> https://bugs.freedesktop.org/attachment.cgi?id=81244&action=edit
rendering with Mesa d282f4ea9b99e4eefec8ce0664cdf49d53d7b052
Trine 2 colors/lighting are wrong with Mesa 9.2 and current git
(d282f4ea9b99e4eefec8ce0664cdf49d53d7b052) on a Radeon HD 6770 Juniper XT.
Game renders correctly using the Catalyst drivers.
Colors are wrong enough to make some puzzles unsolvable because portions of the
screen are too dark to see.
Sample apitrace is at
https://docs.google.com/file/d/0B8G3Ivdx_-JNTV96YjgyNWplZ0U/edit?usp=sharing
Attached screenshots were generated using glretrace -b -S 5670984
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=65714
GitLab Migration User <gitlab-migration(a)fdo.invalid> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |MOVED
Status|NEW |RESOLVED
--- Comment #4 from GitLab Migration User <gitlab-migration(a)fdo.invalid> ---
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.
You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/443.
--
You are receiving this mail because:
You are the assignee for the bug.