dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[Bug 92936] Tonga powerplay isssues
by bugzilla-daemon＠freedesktop.org 30 Nov '18

30 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=92936 Bug ID: 92936 Summary: Tonga powerplay isssues Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com Created attachment 119627 --> https://bugs.freedesktop.org/attachment.cgi?id=119627&action=edit dmesg Testing the amdgpu-powerplay brandh I have several issues. The first and possibly the cause of others (so for now I won't do separate bugs) is on boot I see - Can't find requested voltage id in vdd_dep_on_sclk table! Testing Games/demos all is good and perf is as expected. Testing UVD however and perf is way worse than before powerplay. I see in dmesg - [ 1818.011402] Failed to send Message. [ 1818.011407] Failed to send Previous Message. After doing this I also may no longer get good perf from gamed/demos. Trying to force high for the uvd test doesn't help and I notice another issue - /sys/class/drm/card0/device/power_dpm_force_performance_level is auto to start with, if I echo high > it works = GPU gets hotter, but I can't change it back. If I echo auto > ... then cat it, it will still say high and GPU remains hot. Separately when I quit X I may get some new errors in dmesg Nov 12 11:36:50 ph4 kernel: Failed to send Previous Message. Nov 12 11:36:50 ph4 kernel: last message repeated 2 times Nov 12 11:36:50 ph4 kernel: unforce pcie level failed! -- You are receiving this mail because: You are the assignee for the bug.

1 26

[Bug 93649] [radeonsi] Graphics lockup while playing tf2
by bugzilla-daemon＠freedesktop.org 27 Nov '18

27 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=93649 Bug ID: 93649 Summary: [radeonsi] Graphics lockup while playing tf2 Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: matthew(a)mjdsystems.ca QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 120925 --> https://bugs.freedesktop.org/attachment.cgi?id=120925&action=edit Kernel dmesg around the time of the lockup. After a period of time playing the latest version of TF2, my GPU locks up. After the kernel tries to reset, the X becomes stuck and won't work. The rest of the system is fine however. Sometimes, the GPU will reset successfully and continue working, only to lockup later, eventually freezing X. Hardware: GPU: Gigabyte Radeon HD 7970 Ghz edition OC CPU: AMD Phenom ii X6 1100T MB: Asus Crosshair IV Formula Software: Mesa: 11.1.0 DRM: 2.4.65 LLVM: 3.7.0 X: 1.17.4 DDX: 7.6.1 Kernel: 4.3.3 I have a dmesg with debug turned on and a strace of X from around the time it crashes (attached). I reduced the log file to the relevant bits, as they are quite large. I'll retry with latest git, see if it helps anywhere. -- You are receiving this mail because: You are the assignee for the bug.

1 81

[Bug 93829] [Wine] Lockup with MotoGP 2
by bugzilla-daemon＠freedesktop.org 02 Nov '18

02 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=93829 Bug ID: 93829 Summary: [Wine] Lockup with MotoGP 2 Product: Mesa Version: 11.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: geecko.dev(a)free.fr QA Contact: dri-devel(a)lists.freedesktop.org Current stack: - wine 1.9.1 - mesa 11.1.1 - xf86-video-ati 7.6.1 - xorg-server 1.18.0 - linux 4.3.3 HD 7950 I have been trying to run MotoGP 2 on my desktop. It runs perfectly with all settings maxed out (vsync disabled). After a few minutes of playing the entire computer locks up. It's fairly random. All particles ingame are wrongly colored but I suspect it's a Wine issue. I have it on my laptop with the same stack and Intel graphics. I'll try to gather as much information as I can. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 102401] New: 4.2 RC5
by bugzilla-daemon＠bugzilla.kernel.org 10 Oct '18

10 Oct '18

https://bugzilla.kernel.org/show_bug.cgi?id=102401 Bug ID: 102401 Summary: 4.2 RC5 Product: Drivers Version: 2.5 Kernel Version: Radeon Displayport Audio Warping 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: contrib(a)kliznoe.com Regression: No I'm having issues with Linux 4.2 RC5 with the Displayport audio being deeper then normal. Doesn't seem to happen with 4.1.3 with a backported patch from https://bugzilla.kernel.org/attachment.cgi?id=183611 -- You are receiving this mail because: You are watching the assignee of the bug.

1 20

[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
by bugzilla-daemon＠freedesktop.org 09 Sep '18

09 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=91305 Bug ID: 91305 Summary: When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec Product: Mesa Version: 10.6 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: devurandom(a)gmx.net QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 117050 --> https://bugs.freedesktop.org/attachment.cgi?id=117050&action=edit screenshot I ran `john --test=0 --verbosity=5` from JohnTheRipper@d8cb9ce98acd26bd917dff4cbb54bdc14b7133f9, which made X crash. I was dropped to VT1, where the messages "radeon 0000:01:00.0: ring 0 stalled for more than ...msec" and "radeon 0000:00:01.0: ring 3 stalled for more than ...msec" where flashing by. Afterwards messages of failed tests were logged (typewrote from attached screenshot): ``` AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0000 address=0x000000041145c040 flags=0x0050] [drm:cik_ring_test [radeon]] *ERROR* radeon: ring 1 test failed (scratch(0x3010C)=0xCAFEDEAD) [drm:cik_ring_test [radeon]] *ERROR* radeon: ring 2 test failed (scratch(0x3010C)=0xCAFEDEAD) [drm:cik_sdma_ring_test [radeon]] *ERROR* radeon: ring 4 test failed (0xCAFEDEAD) [drm:cik_resume [radeon]] *ERROR* cik startup failed on resume radeon 0000:00:01.0: ring 0 stalled for more than 10281msec [drm:cik_ib_test [radeon]] *ERROR* radeon: fence wait failed (-35). [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-35). ``` Since dmesg did not log these errors and journald is not accessible via journalctl ATM ("Error was encountered while opening journal files: Invalid argument"), I sadly cannot give you more accurate logs than the typewrote screenshot. -- You are receiving this mail because: You are the assignee for the bug.

1 16

[Bug 82717] New: OpenCL support for mandelbulber-opencl
by bugzilla-daemon＠freedesktop.org 09 Sep '18

09 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=82717 Priority: medium Bug ID: 82717 Assignee: dri-devel(a)lists.freedesktop.org Summary: OpenCL support for mandelbulber-opencl Severity: normal Classification: Unclassified OS: All Reporter: haagch(a)frickel.club Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Website of the program here: https://sites.google.com/site/mandelbulber/ (Watch out, it uses a weird install script) Start it, go to the OpenCL tab and try to enable OpenCL. A few things that probably need to be addressed. I applied some workarounds to see them all and I don't even know if the OpenCL programs would work after removing all of that stuff. Problem 1: OpenCL Build log: ERROR: Program::build() (-43) That's because of the build paramater -cl-denorms-are-zero that is hardcoded in the source code of mandelbulber. Workarodund 1: sed -i 's/-cl-denorms-are-zero / /g' src/cl_support.cpp Problem 2: OpenCL Build log: input.cl:34:1: error: OpenCL does not support the 'static' storage class specifier So that's not valid in OpenCL 1.1, but for the sake of getting it to "just compile" at least: Workaround 2: for i in /usr/share/mandelbulber/cl/*; do sed -i "s/static //g" $i; done Problem 3: OpenCL Build log: input.cl:323:10: error: cannot combine with previous 'type-name' declaration specifier input.cl:323:15: error: expected identifier or '(' input.cl:324:8: error: expected identifier or '(' input.cl:325:32: error: expected expression � (WTF is random binary data doing here?) That's a weird one that seems to come from whatever clang does. I think clang thinks that "half" is already defined in the OpenCL kernels. Not sure if this is intended. Workaround 3: for i in /usr/share/mandelbulber/cl/*; do sed -i "s/half /halfFOO /g" $i; done for i in /usr/share/mandelbulber/cl/*; do sed -i "s/half)/halfFOO)/g" $i; done Problem 4: OpenCL Build log: �}� OpenCL program built done OpenCL kernel opened OpenCL workgroup size: 256 OpenCL Job size: 480256 terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc I don't think the crash itself is the fault of mesa opencl, because the backtrace looks like this: #0 0x00007fd1154e2d67 in raise () from /usr/lib/libc.so.6 #1 0x00007fd1154e4118 in abort () from /usr/lib/libc.so.6 #2 0x00007fd115dd81f5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6 #3 0x00007fd115dd6076 in ?? () from /usr/lib/libstdc++.so.6 #4 0x00007fd115dd60c1 in std::terminate() () from /usr/lib/libstdc++.so.6 #5 0x00007fd115dd62d8 in __cxa_throw () from /usr/lib/libstdc++.so.6 #6 0x00007fd115dd6869 in operator new(unsigned long) () from /usr/lib/libstdc++.so.6 #7 0x00007fd115dd68c9 in operator new[](unsigned long) () from /usr/lib/libstdc++.so.6 #8 0x00000000004a3683 in CclSupport::InitFractal (this=0x207e200) at ../src/cl_support.cpp:451 #9 0x000000000042cffb in ChangedOpenClEnabled (widget=0x22bdd60, data=0x0) at ../src/callbacks.cpp:2896 #10 0x00007fd11673b3d8 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #11 0x00007fd11674cd5d in ?? () from /usr/lib/libgobject-2.0.so.0 But why is there random binary data in the OpenCL build log? llvm-svn 215809 libclc-git 165.20140816 opencl-headers12 1:1.2.r26859 (not sure if relevant) mesa git from today radeon 7970M pitcairn -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 87738] Please add Image support
by bugzilla-daemon＠freedesktop.org 09 Sep '18

09 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=87738 Bug ID: 87738 Summary: Please add Image support Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: enhancement Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: mercen45(a)gmail.com Hi, Image support is required by darktable (RAW photos processing) as can be seen in the following output, from runnind darktable -d opencl: [opencl_init] opencl related configuration options: [opencl_init] [opencl_init] opencl: 0 [opencl_init] opencl_library: '' [opencl_init] opencl_memory_requirement: 768 [opencl_init] opencl_memory_headroom: 300 [opencl_init] opencl_device_priority: '*/!0,*/*/*' [opencl_init] opencl_size_roundup: 16 [opencl_init] opencl_async_pixelpipe: 0 [opencl_init] opencl_synch_cache: 0 [opencl_init] opencl_number_event_handles: 25 [opencl_init] opencl_micro_nap: 1000 [opencl_init] opencl_use_pinned_memory: 0 [opencl_init] opencl_use_cpu_devices: 0 [opencl_init] opencl_avoid_atomics: 0 [opencl_init] opencl_omit_whitebalance: 0 [opencl_init] [opencl_init] trying to load opencl library: '<system default>' [opencl_init] opencl library 'libOpenCL' found on your system and loaded [opencl_init] found 1 platform [opencl_init] found 1 device [opencl_init] discarding device 0 `AMD OLAND' due to missing image support. [opencl_init] no suitable devices found. [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system. [opencl_init] initial status of opencl enabled flag is OFF. Not sure if anything else is needed to get OpenCL to work in darktable but it would be very sweet to be able to get that with open source drivers. Thanks, Thomas -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 68085] New: Xorg crash in do_winsys_init
by bugzilla-daemon＠freedesktop.org 31 Aug '18

31 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=68085 Priority: medium Bug ID: 68085 Assignee: dri-devel(a)lists.freedesktop.org Summary: Xorg crash in do_winsys_init Severity: normal Classification: Unclassified OS: All Reporter: luto(a)mit.edu Hardware: Other Status: NEW Version: git Component: Drivers/DRI/Radeon Product: Mesa Created attachment 84033 --> https://bugs.freedesktop.org/attachment.cgi?id=84033&action=edit Relevant bits of dmesg My box has mgag200 primary and radeon (HD7750) secondary. Xorg crashes on startup in do_winsys_init, which is passed fd = -1. The crash is because drmGetVersion returns NULL. 'rmmod radeon' allows X to start (but without the radeon device). This is Fedora 19, fully up to date. The install disk has the same problem. I'm not sure where fd is supposed to be set to something real, so this bug might be targeting the wrong thing. (gdb) bt full [10/139] #0 do_winsys_init (ws=0x2ff7f20) at radeon_drm_winsys.c:212 gem_info = {gart_size = 0, vram_size = 0, vram_visible = 0} retval = <optimized out> version = <optimized out> #1 radeon_drm_winsys_create (fd=-1) at radeon_drm_winsys.c:617 ws = 0x2ff7f20 #2 0x00007fc2dd8fd359 in create_screen (fd=<optimized out>) at target.c:11 radeon = <optimized out> screen = <optimized out> #3 0x00007fc2ddbc5c32 in dri2_init_screen (sPriv=0x2ff7e00) at dri2.c:888 configs = <optimized out> screen = 0x2ff7e90 pscreen = <optimized out> throttle_ret = 0x0 #4 0x00007fc2dae2e2dd in driCreateNewScreen (scrn=0, extensions=0x7fc2df941b50 <loader_extensions>, driver_configs=0x2f76700, data=0x2f76660) at ../../../../src/mesa/drivers/dri/common/drisw_util.c:70 emptyExtensionList = {0x0} psp = 0x2ff7e00 #5 0x00007fc2df713b91 in __glXDRIscreenProbe (pScreen=0x2f473b0) at glxdriswrast.c:458 driverName = 0x7fc2df72e2a6 "swrast" screen = 0x2f76660 #6 0x00007fc2df71315a in GlxExtensionInit () at glxext.c:355 glxScreen = <optimized out> extEntry = <optimized out> pScreen = 0x2f473b0 i = 0 p = 0x7fc2df941b20 <__glXDRISWRastProvider> stack = <optimized out> glx_provided = 0 #7 0x00000000004ba1a1 in InitExtensions (argc=argc@entry=1, argv=argv@entry=0x7fff9f7860a8) at ../../../mi/miinitext.c:337 i = <optimized out> ext = <optimized out> #8 0x00000000004262e0 in main (argc=1, argv=0x7fff9f7860a8, envp=<optimized out>) at main.c:208 i = <optimized out> alwaysCheckForInput = {0, 1} -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 92039] glxinfo: Error: couldn't find RGB GLX visual or fbconfig; GetVisualConfigs returns 0 visuals; All fbconfigs have VisDepth = 0
by bugzilla-daemon＠freedesktop.org 31 Aug '18

31 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=92039 Bug ID: 92039 Summary: glxinfo: Error: couldn't find RGB GLX visual or fbconfig; GetVisualConfigs returns 0 visuals; All fbconfigs have VisDepth = 0 Product: Mesa Version: 10.1 Hardware: All OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: mikolaj.chadzynski(a)mobica.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 118341 --> https://bugs.freedesktop.org/attachment.cgi?id=118341&action=edit XOrg.0.log glxinfo displays visuals correctly for mesa 9.2.5 (SW rendering works ok - checked with glxgears) but when mesa updated to 10.1.2 I'm getting error: libGL error: failed to load driver: radeonsi libGL error: failed to load driver: swrast Error: couldn't find RGB GLX visual or fbconfig Error: couldn't find RGB GLX visual or fbconfig xdpyinfo returns only 3 X visuals (for mesa 9.2.5 it was about 100) glxinfo return 0 GLX visuals and all GLXFBConfigs have VisDepth = 0 Traced in libGL.so (glxect.c): GetVisualConfigs returns 0 visuals. Answering this question would help: Where in mesa creating/getting information about visuals is done? XOrg.O.log shows no error. I suspect the problem is in radeonsi_drv.so, but for sure it's in Mesa. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 88925] GPU lockup in XCOM with R270X
by bugzilla-daemon＠freedesktop.org 31 Aug '18

31 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=88925 Bug ID: 88925 Summary: GPU lockup in XCOM with R270X Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: dex+fdobugzilla(a)dragonslave.de Created attachment 113074 --> https://bugs.freedesktop.org/attachment.cgi?id=113074&action=edit First stall I'm seeing a constant number of GPU lockups in this game. About 5-10 Minutes in Game right after anything happens on screen that looks like it may need some more GPU power it freezes. Hardware: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Pitcairn (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device 3036 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 34 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at fea00000 (64-bit, non-prefetchable) [size=256K] Region 4: I/O ports at e000 [size=256] Expansion ROM at fea40000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee00000 Data: 0000 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [270 v1] #19 Capabilities: [2b0 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable+, Smallest Translation Unit: 00 Capabilities: [2c0 v1] #13 Capabilities: [2d0 v1] #1b Kernel driver in use: radeon Software: * Kernel 3.19.0-rc7-13532-g1b7a4a0 * xorg-server 1.16.3 * llvm SVN 227800 * Mesa 10.5.0-devel (git-af8fd69) * xf86-video-ati 7.5.0 -- You are receiving this mail because: You are the assignee for the bug.

1 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016