dri-devel September 2014

dri-devel@lists.freedesktop.org

173 participants
1045 discussions

[Bug 44647] New: [wine regression] Call of Duty 4: Intro videos renders garbage
by bugzilla-daemon＠freedesktop.org 20 Apr '16

20 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=44647 Bug #: 44647 Summary: [wine regression] Call of Duty 4: Intro videos renders garbage Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se Created attachment 55392 --> https://bugs.freedesktop.org/attachment.cgi?id=55392 Screenshot of broken video Intro videos in the game Call of Duty 4 (running with Wine) no longer renders correctly, bisecting leads to this: e8139ebf583acf37150a8b341bcbef6b924a7792 is the first bad commit commit e8139ebf583acf37150a8b341bcbef6b924a7792 Author: Mathias Fröhlich <Mathias.Froehlich(a)gmx.net> Date: Tue Jul 26 07:05:10 2011 +0200 r600g: Replace needless flush in texture upload. Replace pipe->flush() with pipe->texture_barrier() in the texture upload path for the staging texture. This should be enough to get data out of the gpu caches ready to be read for texture fetch. :040000 040000 b3f16d1a114f54d753ba7845b697888307f6246e faab26149053fdb2fb65d81bb2a777a77e130de2 M src Adding the flush back fixes the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 7

[Bug 69623] New: Pink Pony misrenders - - shader requires 126 registers
by bugzilla-daemon＠freedesktop.org 19 Apr '16

19 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=69623 Priority: medium Bug ID: 69623 Assignee: dri-devel(a)lists.freedesktop.org Summary: Pink Pony misrenders - - shader requires 126 registers Severity: normal Classification: Unclassified OS: Linux (All) Reporter: sa(a)whiz.se Hardware: x86 (IA32) Status: NEW Version: 9.2 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 86224 --> https://bugs.freedesktop.org/attachment.cgi?id=86224&action=edit Screenshot of bug The game Pink Pony (http://code.google.com/p/pink-pony/) does not render correctly with the r600g driver and Mesa 9.2, see attached screenshot. The following error is printed in the terminal: EE ../../../../../../src/gallium/drivers/r600/r600_shader.c:1580 r600_shader_from_tgsi - GPR limit exceeded - shader requires 126 registers EE ../../../../../../src/gallium/drivers/r600/r600_shader.c:158 r600_pipe_shader_create - translation from TGSI failed ! EE ../../../../../../src/gallium/drivers/r600/r600_state_common.c:754 r600_shader_select - Failed to build shader variant (type=0) -12 I'm not sure if this is the same problem as bug 68527. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 7.2.0 -- xserver: 1.12.4 -- mesa: 9.2 -- drm: 2.4.46 -- kernel: 3.11 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 80673] New: XCOM: Enemy Unknown - Wrong read access when starting the game
by bugzilla-daemon＠freedesktop.org 12 Apr '16

12 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=80673 Priority: medium Bug ID: 80673 Assignee: dri-devel(a)lists.freedesktop.org Summary: XCOM: Enemy Unknown - Wrong read access when starting the game Severity: normal Classification: Unclassified OS: Linux (All) Reporter: freedesktop(a)psydk.org Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 101971 --> https://bugs.freedesktop.org/attachment.cgi?id=101971&action=edit callstack of the wrong read access Some background: I am trying to understand why "XCOM: Enemy Uknown" (a game that was released for Linux x64 last week on Steam), leads to crashes when running with the open source Radeon driver. The people who did the port do not officialy support the open source driver but seems to be open to the idea of making it run on it. My system: Ubuntu 14.04 x64 Readon HD 4870 Mesa 10.1.3 Unfortunately that Radeon model is not supported by AMD's closed source driver. However, the game runs very well with the open source driver, with the exception of several random crashes. This bug report is one of the problem I have found and for which I have some information. The main crash I was experimenting was corrupting the heap, so I used a tool to detect illegal read and write accesses. The first problem it found is an illegal read access at the start of the game, after the different logos, when the main menu is about to appear. What is happening is that a memcpy with a size of 1360 bytes is made with a source buffer of only 1280 bytes in u_upload_data(). I will attach the callstack to this ticket. In that context, the entry point in the driver is: vbo_exec_DrawRangeElementsBaseVertex(GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex) Here are the values of the parameters: --------------------------------------------------------------- mode: 4 (GL_TRIANGLES) start: 0 end: 16 count: 24 type: 5123 (GL_UNSIGNED_SHORT) indices: 72 bytes: 00 00 02 00 03 00 00 00 01 00 02 00 04 00 06 00 07 00 04 00 05 00 06 00 08 00 0a 00 0b 00 08 00 09 00 0a 00 0c 00 0e 00 0f 00 0c 00 0d 00 0e 00 00 00 04 00 06 00 00 00 06 00 02 00 01 00 03 00 07 00 01 00 07 00 05 00 reordered as 36 u16: 0000 0002 0003 0000 0001 0002 0004 0006 0007 0004 0005 0006 0008 000a 000b 0008 0009 000a 000c 000e 000f 000c 000d 000e 0000 0004 0006 0000 0006 0002 0001 0003 0007 0001 0007 0005 basevertex: 0 --------------------------------------------------------------- Now I'm no expert in OpenGL and it is the first time I look at Mesa code, so I can't identify the main reason for the error. Hopefully you will have a clue. A tip to debug the game: if you have Steam and the game, I renamed the main exectuable in ".../Steam/SteamApps/common/XCom-Enemy-Unknown/binaries/linux/" named "game.x86_64" as "game.x86_64_real" and created a shell script named "game.x86_64" that performs necessary settings for debugging and then launch "game.x86_64_real". In my case I am setting LD_PRELOAD with a library that catches malloc() calls and fences the buffer before returning it. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 78717] New: radeon: Failed to allocate a buffer
by bugzilla-daemon＠freedesktop.org 05 Apr '16

05 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=78717 Priority: medium Bug ID: 78717 Assignee: dri-devel(a)lists.freedesktop.org Summary: radeon: Failed to allocate a buffer Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mmstickman(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/radeonsi Product: Mesa When you set shadows to Ultra in the recently released open source game, Tesseract, the game will segfault with the following: radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 failed allocating shadow atlas! MSAA also seems to hang the entire machine -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 72701] New: Screen freeze when using radeon driver
by bugzilla-daemon＠bugzilla.kernel.org 27 Mar '16

27 Mar '16

https://bugzilla.kernel.org/show_bug.cgi?id=72701 Bug ID: 72701 Summary: Screen freeze when using radeon driver Product: Drivers Version: 2.5 Kernel Version: 3.13 and 3.14 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: banjacnikola(a)openmailbox.org Regression: No I got this problem with all distributions using new kernels, that I tried to boot from live CD, as well as the ones I have on the hard drive. Faster booting ones manage to boot before they freeze, while slower ones freeze in the middle of booting process. [klod@klod ~]$ lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6520G] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] When I turn off discrete GPU in my laptop's BIOS, it works well. -- You are receiving this mail because: You are watching the assignee of the bug.

1 24

[Bug 34643] New: ut2004/doom3 looping in submenu on r300g/PageFlip
by bugzilla-daemon＠freedesktop.org 19 Mar '16

19 Mar '16

https://bugs.freedesktop.org/show_bug.cgi?id=34643 Summary: ut2004/doom3 looping in submenu on r300g/PageFlip Product: Mesa Version: git Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: krzysztof.krakowiak(a)gmail.com Created an attachment (id=43736) --> (https://bugs.freedesktop.org/attachment.cgi?id=43736) gdb/ut2k4 output and backraces. ut2004(32/64bit) and doom3(32bit) are looping everytime in submenu on r300g/PageFlip. I believe that bug occured during last two weeks, but bisecting would be hard, because I was bisecting for: https://bugs.freedesktop.org/show_bug.cgi?id=34418 And everytime supertuxkart wasnt working, ut2k4 also and vice versa, altough bugs were definitely different. Now previous bug is fixed(which affected only 64bit apps), but ut2004/doom3 got very similar behaviour(like looped video tape or something, moving forward and back), similar spam in console, but a bit different at output. Disabling PageFLip fixes this problem definitely, but I was happpy pflip user from a long time. Kernel is fresh D-R-T, DDX/DRM/Mesa from master. --- UT2004 dmesg --- [...] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xe [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x1f [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xe [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x1f [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [...] --- EOF UT2004 dmesg --- --- UT2004 gdb output/backtrace --- [...] [Thread 0x7fffe50cd700 (LWP 5934) exited] [New Thread 0x7fffe50cd700 (LWP 5935)] [Thread 0x7fffe50cd700 (LWP 5935) exited] [New Thread 0x7fffe50cd700 (LWP 5936)] [...] [Thread 0x7fffe50cd700 (LWP 6540) exited] [New Thread 0x7fffe50cd700 (LWP 6541)] radeon: The kernel rejected CS, see dmesg for more information. [Thread 0x7fffe50cd700 (LWP 6541) exited] [...] Program received signal SIGINT, Interrupt. 0x00007ffff6e0a1f3 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff6e0a1f3 in poll () from /lib64/libc.so.6 #1 0x00007ffff65eac6a in ?? () from /usr/lib64/libxcb.so.1 #2 0x00007ffff65ec2ff in xcb_wait_for_reply () from /usr/lib64/libxcb.so.1 #3 0x00007ffff684392d in _XReply () from /usr/lib64/libX11.so.6 #4 0x00007fffe6c1748c in DRI2GetBuffersWithFormat () from /opt/xorg/lib64/libGL.so.1 #5 0x00007fffe6c14bf9 in dri2GetBuffersWithFormat () from /opt/xorg/lib64/libGL.so.1 #6 0x00007fffe56de4d8 in dri2_allocate_textures () from /opt/xorg/lib64/dri/gallium/r300_dri.so #7 0x00007fffe56dfb77 in dri_st_framebuffer_validate () from /opt/xorg/lib64/dri/gallium/r300_dri.so #8 0x00007fffe573f132 in st_framebuffer_validate () from /opt/xorg/lib64/dri/gallium/r300_dri.so #9 0x00007fffe5740916 in st_manager_validate_framebuffers () from /opt/xorg/lib64/dri/gallium/r300_dri.so #10 0x00007fffe58e3c1e in st_validate_state () from /opt/xorg/lib64/dri/gallium/r300_dri.so #11 0x00007fffe58ebb3a in st_Clear () from /opt/xorg/lib64/dri/gallium/r300_dri.so #12 0x0000000000d291d9 in FOpenGLRenderInterface::Clear(int, FColor, int, float, int, unsigned int) () #13 0x000000000069d234 in UGameEngine::Draw(UViewport*, int, unsigned char*, int*) () #14 0x0000000000d1d106 in USDLViewport::Repaint(int) () #15 0x0000000000d1ab09 in USDLClient::Tick() () #16 0x00000000006a0f54 in UGameEngine::Tick(float) () #17 0x000000000053d2a3 in CMainLoop::RunLoop() () #18 0x000000000053344f in ?? () #19 0x000000000052f1a0 in main () --- UT2004 gdb output/backtrace --- --- Doom3 output --- [...] radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information [...] --- EOF Doom3 output --- TIP: For full logs, look into attachements (but nothing special in xorg.log) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 5

[Bug 60523] New: Lockup with radeon DPM on Radeon HD5770 (Juniper)
by bugzilla-daemon＠bugzilla.kernel.org 13 Mar '16

13 Mar '16

https://bugzilla.kernel.org/show_bug.cgi?id=60523 Bug ID: 60523 Summary: Lockup with radeon DPM on Radeon HD5770 (Juniper) Product: Drivers Version: 2.5 Kernel Version: 3.10-drm-next-3.11 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: tdroste(a)gmx.de Regression: No Created attachment 106814 --> https://bugzilla.kernel.org/attachment.cgi?id=106814&action=edit dmesg | grep -iE "drm|radeon|power|uvd" after starting a video with mplayer I have some not always reproducible lockup with the latest DPM code. There are 2 scenarios: 1. PC boots, DPM is active and reports different power states and levels in dmesg, but does not change the power level (it's always at power level 2) 2. mplayer is started and plays a video with UVD. DPM switches the power state to UVD and switches between powerlevel 0 and 2 while playing the video 3. When closing mplayer there are 2 possible outcomes: a) DPM switches the power state back to performance and stays in power level 0 or 1. This will stay until something triggers it to switch to power level 2 again. As soon as it's in power level 2 again it's never changing back. b) PC locks up, display is black and VT switch doesn't work until I SysRq+REISUB to reboot the machine Scenario b is harder to trigger but it happened at least 2 times today. dmesg | grep -iE "drm|radeon|power|uvd" -- You are receiving this mail because: You are watching the assignee of the bug.

1 78

[Bug 72087] New: Black levels incorrect during video playback at first
by bugzilla-daemon＠freedesktop.org 26 Feb '16

26 Feb '16

https://bugs.freedesktop.org/show_bug.cgi?id=72087 Priority: medium Bug ID: 72087 Assignee: dri-devel(a)lists.freedesktop.org Summary: Black levels incorrect during video playback at first Severity: normal Classification: Unclassified OS: Linux (All) Reporter: pyrodex(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 89920 --> https://bugs.freedesktop.org/attachment.cgi?id=89920&action=edit Xorg log file I am currently running XBMC nightly and have been working with fritsch via the XBMC forums to diagnose this issue. My current setup is as follows: AMD A6-3500 APU with Radeon(tm) HD Graphics 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6530D] 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek HDMI Audio [Radeon HD 6500D and 6400G-6600G series] Ubuntu 13.10 running 2.13-rc1 with mesa git (10.0~git201311181342.37827~ubuntu13.10.1) My HTPC is connected to a Denon AVR-991 then connected to a Panasonic 50" Plasma. The Denon is setup for 0-255 levels and the HTPC via XBMC is set for 16-235 due to it being "darker" than normal after the leap from windows. Recently I've added an xrandr setting to turner Dither to ON since before the setting it would occasionally switch black levels through video play and with the new setting it ONLY does it on startup of video playback and then corrects itself 2-3 seconds later. I am in the process of taking a video now for reference and will upload it later today. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 71194] New: Null Pointer dereference in drm_send_blank_event
by bugzilla-daemon＠freedesktop.org 26 Feb '16

26 Feb '16

https://bugs.freedesktop.org/show_bug.cgi?id=71194 Priority: medium Bug ID: 71194 Assignee: dri-devel(a)lists.freedesktop.org Summary: Null Pointer dereference in drm_send_blank_event Severity: normal Classification: Unclassified OS: Linux (All) Reporter: ronaldmik(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 88570 --> https://bugs.freedesktop.org/attachment.cgi?id=88570&action=edit Screenshot of TV with kernel panic affected kernels: 3.11.3, 3.11.6, 3.12-rc7, 3.12-drm-nightly (november 3rd) Reproduce: Start Xorg Start some gl application and see the kernel crashing -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 70409] New: Radeon 7730M discrete GPU use crashes DRI PRIME, appears to be using r600 driver
by bugzilla-daemon＠freedesktop.org 26 Feb '16

26 Feb '16

https://bugs.freedesktop.org/show_bug.cgi?id=70409 Priority: medium Bug ID: 70409 Assignee: dri-devel(a)lists.freedesktop.org Summary: Radeon 7730M discrete GPU use crashes DRI PRIME, appears to be using r600 driver Severity: normal Classification: Unclassified OS: Linux (All) Reporter: calcprogrammer1(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI I am trying to get DRI PRIME working on my AMD dual-GPU laptop. hp dv6z-7000 AMD A10-4600 APU with Radeon HD 7660G (ARUBA) AMD Radeon HD 7730M (VERDE) discrete GPU, 2GB VRAM Ubuntu GNOME 13.10 Custom-built kernel 3.11-rc7 from drm-next-3.13-wip branch (for DPM) I'm using the Ubuntu-provided xorg, mesa, glamor, and libdrm packages. I had to compile my own xserver-xorg-video-ati/radeon packages with glamor acceleration support enabled. With this I can confirm glamor acceleration is being used with the 7660G on r600 and it works well. Now, I want to enable DRI PRIME to use the 7730M with games. adam@Adam-dv6z-7000:~$ xrandr --listproviders Providers: number : 3 Provider 0: id: 0x6c cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 2 name:radeon Provider 1: id: 0x45 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 0 associated providers: 2 name:radeon Provider 2: id: 0x45 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 0 associated providers: 2 name:radeon adam@Adam-dv6z-7000:~$ xrandr --setprovideroffloadsink 0x45 0x6C adam@Adam-dv6z-7000:~$ DRI_PRIME=1 glxinfo | grep renderer When I run that third line, X crashes immediately with a segfault and automatically restarts GDM to the login screen. I will attach a Xorg log to this bug report after I post it and run the commands. -- You are receiving this mail because: You are the assignee for the bug.

1 14

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2014