dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 83022] New: memory leak
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=83022 Priority: medium Bug ID: 83022 Assignee: dri-devel(a)lists.freedesktop.org Summary: memory leak Severity: normal Classification: Unclassified OS: All Reporter: pavol(a)klacansky.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa I am using VisIt to produce movies, however it seems that each state file leak memory and I cannot process all of them. I have tested it on nvidia workstation with proprietary drivers without problem. Can you point me how to identify if it is a driver's problem or VisIt's? -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 83012] New: horrible performance with vblank_mode=1 which is the default
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=83012 Priority: medium Bug ID: 83012 Assignee: dri-devel(a)lists.freedesktop.org Summary: horrible performance with vblank_mode=1 which is the default Severity: normal Classification: Unclassified OS: All Reporter: aaalmosss(a)gmail.com Hardware: Other Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa For example, Unigine Tropics benchmark gives 20fps, but with vblank_mode=0 it's 54fps. Games that don't turn off vsync by themselves suffer from this as well. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 82919] New: Screen flickers when playing video.
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=82919 Priority: medium Bug ID: 82919 Assignee: dri-devel(a)lists.freedesktop.org Summary: Screen flickers when playing video. Severity: normal Classification: Unclassified OS: All Reporter: barz621(a)gmail.com Hardware: Other Status: NEW Version: 10.2 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 105059 --> https://bugs.freedesktop.org/attachment.cgi?id=105059&action=edit Xorg.0.log With HW acceleration enabled on the r600 driver using gstreamer gst-vaapi the screen flickers when the uvd changes its power state. This happens when you play a video on firefox (youtube, vimeo vine etc.) or with vlc. It flickers upon starting/ stopping and then a few more times. The monitor is connected with DP in case it matters. glxinfo: glxinfo | grep -i opengl OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.5 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.5 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.2.5 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0 OpenGL ES profile extensions: This is what happens when you start youtube play one video and stop it. journal: journalctl -f -- Logs begin at Mon 2013-04-22 10:20:09 EEST. -- Aug 21 22:41:16 mainland kernel: status: c Aug 21 22:41:16 mainland kernel: switching to power state: Aug 21 22:41:16 mainland kernel: ui class: performance Aug 21 22:41:16 mainland kernel: internal class: none Aug 21 22:41:16 mainland kernel: caps: Aug 21 22:41:16 mainland kernel: uvd vclk: 0 dclk: 0 Aug 21 22:41:16 mainland kernel: power level 0 sclk: 10000 mclk: 15000 vddc: 950 vddci: 950 Aug 21 22:41:16 mainland kernel: power level 1 sclk: 60000 mclk: 100000 vddc: 1100 vddci: 1100 Aug 21 22:41:16 mainland kernel: power level 2 sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100 Aug 21 22:41:16 mainland kernel: status: r Aug 21 22:42:42 mainland kernel: switching from power state: Aug 21 22:42:42 mainland kernel: ui class: performance Aug 21 22:42:42 mainland kernel: internal class: none Aug 21 22:42:42 mainland kernel: caps: Aug 21 22:42:42 mainland kernel: uvd vclk: 0 dclk: 0 Aug 21 22:42:42 mainland kernel: power level 0 sclk: 10000 mclk: 15000 vddc: 950 vddci: 950 Aug 21 22:42:42 mainland kernel: power level 1 sclk: 60000 mclk: 100000 vddc: 1100 vddci: 1100 Aug 21 22:42:42 mainland kernel: power level 2 sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100 Aug 21 22:42:42 mainland kernel: status: c Aug 21 22:42:42 mainland kernel: switching to power state: Aug 21 22:42:42 mainland kernel: ui class: none Aug 21 22:42:42 mainland kernel: internal class: uvd Aug 21 22:42:42 mainland kernel: caps: video Aug 21 22:42:42 mainland kernel: uvd vclk: 54000 dclk: 40000 Aug 21 22:42:42 mainland kernel: power level 0 sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100 Aug 21 22:42:42 mainland kernel: power level 1 sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100 Aug 21 22:42:42 mainland kernel: power level 2 sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100 Aug 21 22:42:42 mainland kernel: status: r Aug 21 22:42:53 mainland kernel: switching from power state: Aug 21 22:42:53 mainland kernel: ui class: none Aug 21 22:42:53 mainland kernel: internal class: uvd Aug 21 22:42:53 mainland kernel: caps: video Aug 21 22:42:53 mainland kernel: uvd vclk: 54000 dclk: 40000 Aug 21 22:42:53 mainland kernel: power level 0 sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100 Aug 21 22:42:53 mainland kernel: power level 1 sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100 Aug 21 22:42:53 mainland kernel: power level 2 sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100 Aug 21 22:42:53 mainland kernel: status: c Aug 21 22:42:53 mainland kernel: switching to power state: Aug 21 22:42:53 mainland kernel: ui class: performance Aug 21 22:42:53 mainland kernel: internal class: none Aug 21 22:42:53 mainland kernel: caps: Aug 21 22:42:53 mainland kernel: uvd vclk: 0 dclk: 0 Aug 21 22:42:53 mainland kernel: power level 0 sclk: 10000 mclk: 15000 vddc: 950 vddci: 950 Aug 21 22:42:53 mainland kernel: power level 1 sclk: 60000 mclk: 100000 vddc: 1100 vddci: 1100 Aug 21 22:42:53 mainland kernel: power level 2 sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100 Aug 21 22:42:53 mainland kernel: status: r Aug 21 22:43:00 mainland kernel: switching from power state: Aug 21 22:43:00 mainland kernel: ui class: performance Aug 21 22:43:00 mainland kernel: internal class: none Aug 21 22:43:00 mainland kernel: caps: Aug 21 22:43:00 mainland kernel: uvd vclk: 0 dclk: 0 Aug 21 22:43:00 mainland kernel: power level 0 sclk: 10000 mclk: 15000 vddc: 950 vddci: 950 Aug 21 22:43:00 mainland kernel: power level 1 sclk: 60000 mclk: 100000 vddc: 1100 vddci: 1100 Aug 21 22:43:00 mainland kernel: power level 2 sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100 Aug 21 22:43:00 mainland kernel: status: c Aug 21 22:43:00 mainland kernel: switching to power state: Aug 21 22:43:00 mainland kernel: ui class: none Aug 21 22:43:00 mainland kernel: internal class: uvd Aug 21 22:43:00 mainland kernel: caps: video Aug 21 22:43:00 mainland kernel: uvd vclk: 54000 dclk: 40000 Aug 21 22:43:00 mainland kernel: power level 0 sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100 Aug 21 22:43:00 mainland kernel: power level 1 sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100 Aug 21 22:43:00 mainland kernel: power level 2 sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100 Aug 21 22:43:00 mainland kernel: status: r Aug 21 22:43:02 mainland kernel: switching from power state: Aug 21 22:43:02 mainland kernel: ui class: none Aug 21 22:43:02 mainland kernel: internal class: uvd Aug 21 22:43:02 mainland kernel: caps: video Aug 21 22:43:02 mainland kernel: uvd vclk: 54000 dclk: 40000 Aug 21 22:43:02 mainland kernel: power level 0 sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100 Aug 21 22:43:02 mainland kernel: power level 1 sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100 Aug 21 22:43:02 mainland kernel: power level 2 sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100 Aug 21 22:43:02 mainland kernel: status: c Aug 21 22:43:02 mainland kernel: switching to power state: Aug 21 22:43:02 mainland kernel: ui class: performance Aug 21 22:43:02 mainland kernel: internal class: none Aug 21 22:43:02 mainland kernel: caps: Aug 21 22:43:02 mainland kernel: uvd vclk: 0 dclk: 0 Aug 21 22:43:02 mainland kernel: power level 0 sclk: 10000 mclk: 15000 vddc: 950 vddci: 950 Aug 21 22:43:02 mainland kernel: power level 1 sclk: 60000 mclk: 100000 vddc: 1100 vddci: 1100 Aug 21 22:43:02 mainland kernel: power level 2 sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100 Aug 21 22:43:02 mainland kernel: status: r -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 82791] New: GPU lock when using "Death Dance" in Tales of Maj'Eyal
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=82791 Priority: medium Bug ID: 82791 Assignee: dri-devel(a)lists.freedesktop.org Summary: GPU lock when using "Death Dance" in Tales of Maj'Eyal Severity: major Classification: Unclassified OS: Linux (All) Reporter: bugzilla.20.kamdrimar(a)spamgourmet.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.2 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 104850 --> https://bugs.freedesktop.org/attachment.cgi?id=104850&action=edit dmesg showing GPU lock Symptoms: GPU locks and attempts to recover (screen goes black) and locks again upon recovery. Any further attempt to use X11 (even restarting it) locks the GPU, and system must be rebooted to use X11 again. Steps to reproduce: 1) Download Tales of Maj'Eyal 1.2.3 full for Linux 64-bit - http://te4.org/download 2) Extract the game to a convenient location. 3) Run the t-engine binary from the base game directory, then exit the game. 4) Download a gzip of a character I created - - and extract to: ~/.t-engine/4.0/tome/save/ 5) Run t-engine again, load the save game "Pennies". 6) Use the ability "Death Dance" in game. (If for some reason my save won't work, you need to create a Berserker class character in-game, get it to level 8 and 28 strength, and unlock Death Dance.) Workarounds attempted: use different window manager/DE - Failed, bug is reproducible in KDE4, KDE5, Awesome, and Enlightenment 18 pass radeon.audio=0 to kernel command line at boot - Failed, no effect pass radeon.dpm=0 to kernel - Failed, screen now stays black after GPU lock Note: this bug may be related to other GPU locks I've been experiencing with Mesa 10.2.x, but this is the only repeatable instance of it so far. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 81896] New: GPU reset when running some "John the Ripper" (+ jumbo patch, from Git) OpenCL tests
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=81896 Priority: medium Bug ID: 81896 Assignee: dri-devel(a)lists.freedesktop.org Summary: GPU reset when running some "John the Ripper" (+ jumbo patch, from Git) OpenCL tests Severity: normal Classification: Unclassified OS: Linux (All) Reporter: lbdkmjdf(a)sharklasers.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 103669 --> https://bugs.freedesktop.org/attachment.cgi?id=103669&action=edit mixed outputs I get GPU reset when running some opencl tests from this program from TTY. If I'm running a DE when the lockup happens, the system stops responding. Attached are: - the mixed output from /var/log/syslog and this command: $ R600_DEBUG=cs LWS=128 GWS=9216 ./john --test --format=PBKDF2-HMAC-SHA256-opencl - an attempt to clean it, only leaving the output from "R600_DEBUG=cs" Also notice, there is random garbage after "Build log:", which comes from clGetProgramBuildInfo ( https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/src/commo… , prints "Build log:" in line 768) My system: Hardware: HP dv6, CPU: AMD A6-3400M, GPUs: Radeon HD 6520g (evergreen) + 6750M (north islands) OS: Kubuntu 14.04 Kernel: 3.15.7, and 3.13, both amd64 Mesa 10.3~git1407290730.9a53f9 (from oibaf's PPA, https://launchpad.net/~oibaf/+archive/graphics-drivers ), compiled with LLVM 3.5-rc1. ________________ To reproduce, here's a mini "how to run" for "John The Ripper" + "jumbo" patches: $ git clone https://github.com/magnumripper/JohnTheRipper $ cd JohnTheRipper/src $ ./configure && make $ cd ../run $ ./john --help # prints usage help $ # the following command prints a list of hash format tests that use opencl, separated by spaces. remove the awk part to get one per line: $ ./john --help | grep -Eo '[a-zA-Z0-9-]*-opencl' | awk '{printf "%s ", $0}'; echo To run a test: $ ./john --test --format=$format where $format is one of the formats listed from the previous command The program does verify the output. When it fails, it should print something like "FAILED (get_hash[0](0))". -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 81683] New: [r600g] graphic glitches in Skyrim - failed to build shader
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=81683 Priority: medium Bug ID: 81683 Assignee: dri-devel(a)lists.freedesktop.org Summary: [r600g] graphic glitches in Skyrim - failed to build shader Severity: normal Classification: Unclassified OS: Linux (All) Reporter: 640bugs(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.2 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 103360 --> https://bugs.freedesktop.org/attachment.cgi?id=103360&action=edit Screenshot of graphic problems in Skyrim When playing Skyrim with Mesa 10.2.4, I get graphic glitches at the place of the thieves guild (see screenshot, the floor isn't visible). I am playing with an AMD Radeon 685, Linux 3.15.5-2-ARCH. I noticed these messages in the console. EE r600_shader.c:2188 r600_shader_from_tgsi - GPR limit exceeded - shader requires 127 registers EE r600_shader.c:157 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:750 r600_shader_select - Failed to build shader variant (type=1) -12 Is this bug known? Any ideas or suggestion, how i can help to solve this issue? -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 81192] New: Garbled screen with VDPAU playback and h264
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=81192 Priority: medium Bug ID: 81192 Assignee: dri-devel(a)lists.freedesktop.org Summary: Garbled screen with VDPAU playback and h264 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: sige(a)stripeyc.at Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa Created attachment 102577 --> https://bugs.freedesktop.org/attachment.cgi?id=102577&action=edit dmesg output Whenever I try playing a h264 encoded movie, the system/X11 locks up completely with 3 different symptoms. X freezes, I might be able to move the mousecursor (which doesn't change), was able to log in to the machine remotely and reboot it. X freezes first, full screen is garbled just a few seconds later. Additionally I might be able to move some square, which is likely the "cursor".. garbled as well. I must be honest I didn't try logging in remotely there yet, if the machine itself is still alive. Machie is running: Linux 3.15.4 from the repo and tried on a 3.16rc4 today (Installed that to test against a kernel bug) Xorg is 1.15.2 mesa is 10.2.3 mplayer is SVN-r37224 I tried a mpeg2 video and played it just fine ( mplayer -vo vdpau -vc ffmpeg12vdpau <file> ) I also got two h264 files and it freezes/garbles every time there http://samples.mplayerhq.hu/V-codecs/h264/PAFF/Grey.ts http://samples.mplayerhq.hu/V-codecs/h264/nature_704x576_25Hz_1500kbits.h264 mplayer -vo vdpau -vc ffh264vdpau <file> It reliably just freezes the screen, with the mouse working for a while or completely garbles it. I also had an occurrence of the screen going garbled and then black, back to the garbled screen. Three times or something. Maybe he tried resetting the GPU or something; I don't know. Not sure if I can find any logs from that one. Also: Haven't tried any other codecs yet, that might be supported. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 80876] New: luxrays/slg4 hangs GPU (CEDAR)
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=80876 Priority: medium Bug ID: 80876 Assignee: dri-devel(a)lists.freedesktop.org Summary: luxrays/slg4 hangs GPU (CEDAR) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: awatry(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 102222 --> https://bugs.freedesktop.org/attachment.cgi?id=102222&action=edit luxrays diff/patch to disable image support while reproducing bug. While working on getting the Luxrays slg4 program running (which is invoked as part of the luxmark CL-based raytracing benchmark), I encountered some GPU hangs on the evergreen card I'm using (CEDAR, Radeon 5400-series). Hardware: Core i7-2600k 16GB DDR3 Radeon 5400-series PCI express w/ dual 1080p monitors Software: Mesa: Git master LLVM: 3.5svn drm: fairly recent git libclc: git master + a few extra patches to implement missing built-ins luxrays: From http://src.luxrender.net/luxrays, with the attached patch. Steps: 1) Checkout luxrays source from the mercurial repository 2) Apply patch to disable image support in the renderer 3) Build luxrays from source (cmake). 4) run bin/slg4 5) Watch the UI start to pop-up and the GPU reset. dmesg, kernel source, llvm bitcode to be attached. rlockup_*.c cs trace available as a 35MB gzipped C file (>300MB uncompressed). -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 79431] New: OpenGL OpenCL interop results in corrupted renderbuffer object image
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=79431 Priority: medium Bug ID: 79431 Assignee: dri-devel(a)lists.freedesktop.org Summary: OpenGL OpenCL interop results in corrupted renderbuffer object image Severity: normal Classification: Unclassified OS: All Reporter: pavol(a)klacansky.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa I use APP SDK with OpenCL running on CPU and r600 driver on GPU (AMD Mobility 3650) to compute image. If I use OpenCL image, I get correct result, however if I want to display image using OpenGL (interop), it is corrupted. I create renderbuffer object, than link it with OpenCL (clCreateFromGLRenderbuffer) and then after image was computed I blit it to back buffer. I tested it in lab on nVidia proprietary driver and it works well, I suspect the problem is in renderbuffer sharing. OpenCL is 1.2, OpenGL 3.3. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 79154] New: [Tesseract Game] 4xMSAA Causes Visible Wireframes
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=79154 Priority: medium Bug ID: 79154 Assignee: dri-devel(a)lists.freedesktop.org Summary: [Tesseract Game] 4xMSAA Causes Visible Wireframes Severity: normal Classification: Unclassified OS: All Reporter: mmstickman(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 99678 --> https://bugs.freedesktop.org/attachment.cgi?id=99678&action=edit Screenshot of the wireframes Currently running the latest mesa git with a Radeon HD 7950. Simply set MSAA to 4x to experience this bug. -- 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 September 2019