dri-devel March 2015

dri-devel@lists.freedesktop.org

196 participants
1117 discussions

[Bug 66964] New: GPU fault detected
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=66964 Priority: medium Bug ID: 66964 Assignee: dri-devel(a)lists.freedesktop.org Summary: GPU fault detected Severity: normal Classification: Unclassified OS: All Reporter: udovdh(a)xs4all.nl Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Hello, See https://bugs.freedesktop.org/show_bug.cgi?id=62959 as reference. I turned off RADEON_VA=0 and R600_DEBUG=nodma and after a while I got the output below (and a reboot) while surfing the web, checking videos from youtube, etc. I use git everything on A10-5800K which has ARUBA (Cayman) GPU with kernel.org 3.9.9. What is the cause? And how can we fix this? Jul 16 16:00:01 surfplank2 kernel: [178650.498628] radeon 0000:00:01.0: GPU fault detected: 147 0x0db67102 Jul 16 16:00:01 surfplank2 kernel: [178650.498633] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00001EDB Jul 16 16:00:01 surfplank2 kernel: [178650.498635] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06071002 Jul 16 16:00:01 surfplank2 kernel: [178650.498638] radeon 0000:00:01.0: GPU fault detected: 147 0x0db67102 Jul 16 16:00:01 surfplank2 kernel: [178650.498640] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498643] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498645] radeon 0000:00:01.0: GPU fault detected: 146 0x01f67104 Jul 16 16:00:01 surfplank2 kernel: [178650.498647] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498649] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498652] radeon 0000:00:01.0: GPU fault detected: 146 0x02067104 Jul 16 16:00:01 surfplank2 kernel: [178650.498654] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498656] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498658] radeon 0000:00:01.0: GPU fault detected: 146 0x02067104 Jul 16 16:00:01 surfplank2 kernel: [178650.498660] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498662] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498664] radeon 0000:00:01.0: GPU fault detected: 147 0x03b67102 Jul 16 16:00:01 surfplank2 kernel: [178650.498667] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498669] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498671] radeon 0000:00:01.0: GPU fault detected: 147 0x03c67102 Jul 16 16:00:01 surfplank2 kernel: [178650.498673] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498675] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498677] radeon 0000:00:01.0: GPU fault detected: 147 0x03c67102 Jul 16 16:00:01 surfplank2 kernel: [178650.498679] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498681] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498683] radeon 0000:00:01.0: GPU fault detected: 147 0x03c67102 Jul 16 16:00:01 surfplank2 kernel: [178650.498685] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498687] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498690] radeon 0000:00:01.0: GPU fault detected: 146 0x02067104 Jul 16 16:00:01 surfplank2 kernel: [178650.498692] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498694] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06071004 Jul 16 16:00:01 surfplank2 kernel: [178650.498711] radeon 0000:00:01.0: GPU fault detected: 146 0x09767104 Jul 16 16:00:01 surfplank2 kernel: [178650.498713] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 Jul 16 16:00:01 surfplank2 kernel: [178650.498715] radeon 0000:00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 Kind regards, Udo -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 66961] New: Kernel BUG/Oops during radeon gpu stall
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

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.

1 5

[Bug 66920] New: [llvm backend] flashing textures, no lights in car , no water on GTA IV
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

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.

1 19

[Bug 66883] New: [r600 llvm backend] Assert with 32-bit lightsmark, TF2 when shader dump is enabled
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

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.

1 1

[Bug 66880] New: R600_DEBUG=sb hangs system after playing xonotic, spring
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=66880 Priority: medium Bug ID: 66880 Assignee: dri-devel(a)lists.freedesktop.org Summary: R600_DEBUG=sb hangs system after playing xonotic, spring Severity: normal Classification: Unclassified OS: Linux (All) Reporter: pheldens(a)ziggo.nl Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa linux 3.10.* and before R600_DEBUG=sb radeon 4670 crashes in xonotic and spring after indeterminate time, colours the screen with garbage, does not crash when R600_DEBUG is unset. all I caught so far is a kernel oops output Oops: 0000 [#1] PREEMPT SMP Modules linked in: snd_hda_codec_hdmi snd_cmipci snd_opl3_lib snd_mpu401_uart snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_hda_intel snd_hda_codec snd_hwdep CPU: 0 PID: 1539 Comm: X Not tainted 3.10.0-rc6 #2 Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7596/785GM-E51 (MS-7596), BIOS V2.11 12/08/2010 task: ffff88022e9f9320 ti: ffff880226ca4000 task.ti: ffff880226ca4000 RIP: 0010:[<ffffffff813e74ca>] [<ffffffff813e74ca>] radeon_fence_process+0x8a/0x150 RSP: 0018:ffff880226ca5c28 EFLAGS: 00010246 RAX: ffffc9001079c598 RBX: 0000000000000002 RCX: ffff880226972da0 RDX: 0000000000000041 RSI: 0000000000000000 RDI: ffff880226972000 RBP: 000000000000000c R08: ffff880226972208 R09: 0000000000000000 R10: 0000000000000005 R11: 0000000000000304 R12: ffff880226972df0 R13: 0000000000000002 R14: ffff880226972000 R15: ffffffff00000000 FS: 00007fe0a9315880(0000) GS:ffff88022fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffc9001079c598 CR3: 00000002241b6000 CR4: 00000000000007f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffff88022695ce00 ffffffff8144f257 0000000000000292 ffffffff81948957 ffff88022eb8b560 ffff880226972000 0000000000000005 ffff880226972000 ffff880226972e20 ffff8802269725f8 0000000000000000 ffffffff813e7fdb Call Trace: [<ffffffff8144f257>] ? __dev_printk+0x37/0xa0 [<ffffffff813e7fdb>] ? radeon_fence_count_emitted+0x1b/0x70 [<ffffffff813fd8cd>] ? radeon_ring_backup+0x3d/0x120 [<ffffffff813d3601>] ? radeon_gpu_reset+0x81/0x210 [<ffffffff813fc930>] ? radeon_gem_wait_idle_ioctl+0xd0/0xf0 [<ffffffff813b0250>] ? drm_ioctl+0x460/0x560 [<ffffffff813fc860>] ? radeon_gem_busy_ioctl+0x120/0x120 [<ffffffff8108e8a4>] ? signal_delivered+0x54/0x70 [<ffffffff8112657a>] ? do_vfs_ioctl+0x8a/0x500 [<ffffffff810a98ce>] ? vtime_account_user+0x6e/0x90 [<ffffffff81126a3d>] ? SyS_ioctl+0x4d/0xa0 [<ffffffff8176bf49>] ? tracesys+0xd0/0xd5 Code: 48 39 d0 73 53 48 89 c3 41 b9 01 00 00 00 41 80 be 58 16 00 00 00 4d 8b a8 e0 0b 00 00 48 8d 41 08 0f 84 86 00 00 00 48 8b 40 10 <8b> 00 48 89 da 89 c0 4c 21 fa 48 09 d0 48 39 c3 76 0c 4c 89 ea RIP [<ffffffff813e74ca>] radeon_fence_process+0x8a/0x150 RSP <ffff880226ca5c28> CR2: ffffc9001079c598 ---[ end trace 2b43f4717e08f222 ]--- -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 66731] New: texture issues in xonotic with llvm+sb and offset mapping
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

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.

1 3

[Bug 66632] New: Very low FPS when video memory is full (GART & ram <-> vram swapping)
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

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.

1 13

[Bug 66349] New: Using SB shader optimization caused segfault in Serious Sam 3: BFE
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

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.

1 10

[Bug 66067] New: Trine 2 color problems on Radeon HD 6770 (Juniper)
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

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.

1 44

[Bug 65611] New: UVD accelerated decoding causes hangs (ARUBA - HD 7540D)
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=65611 Priority: medium Bug ID: 65611 Assignee: dri-devel(a)lists.freedesktop.org Summary: UVD accelerated decoding causes hangs (ARUBA - HD 7540D) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: otaznik(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 80626 --> https://bugs.freedesktop.org/attachment.cgi?id=80626&action=edit relevant dmesg output New UVD VDPAU decoding of VC-1 and MPEG-2 causes some kind of corruption and ultimately hang of driver and whole system on the next try (cursor can be moving for some time, even SysRq can work a few seconds after X totally hangs but then only power off works). Few notes (using mplayer): ffmpeg12vdpau: MPEG1 causes no harm, only decoding is really bad (software decoding works) MPEG2 seems to cause really bad corruption ffvc1vdpau: VC-1 seems to cause problems (like attached dmesg) but not hangs. There have been decoding artifacts too, but it is not the rule. divx and h264 seems to work flawless, unless previous corruption happened. Hardware is ARUBA - A6-5400K Black Edition APU (Radeon HD 7540D). Since this particular hardware seems to be problematic (#65254 #60389) it might be unique to this APU. Test files: VC1 http://samples.mplayerhq.hu/V-codecs/WVC1/Test_1440x576_WVC1_6Mbps.wmv MPEG2 http://samples.mplayerhq.hu/MPEG2/vid_0x80.ts MPEG1 http://samples.mplayerhq.hu/MPEG1/ -- You are receiving this mail because: You are the assignee for the bug.

1 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2015