dri-devel March 2015

dri-devel@lists.freedesktop.org

196 participants
1117 discussions

[Bug 73625] New: rv730 agp unstable while uvd video playback
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=73625 Priority: medium Bug ID: 73625 Assignee: dri-devel(a)lists.freedesktop.org Summary: rv730 agp unstable while uvd video playback Severity: normal Classification: Unclassified OS: All Reporter: roman.elshin(a)gmail.com Hardware: Other Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa While uvd video playback (no difference with mplayer, mpv or xbms) video frequently stops at the loop of several frames, while sound move further. It very similar to video from https://bugs.freedesktop.org/show_bug.cgi?id=73191 but loop is endless (if gpu will not hang there). Sometimes there are visible screen corruptions (color squares) before video looping, sometimes gpu hangs up before visible corruptions. card - rv730 agp, kernels - 3.12.7, 3.13-rc7 and before. mesa, drm, video - from oibaf ppa, i suppose it is current git (own compiled give the same). It looks like disabling ColorTiling2D in xorg.conf.d solve this problem. -- You are receiving this mail because: You are the assignee for the bug.

1 25

[Bug 73619] New: XServer frequently freezes for a few seconds
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=73619 Priority: medium Bug ID: 73619 Assignee: dri-devel(a)lists.freedesktop.org Summary: XServer frequently freezes for a few seconds Severity: normal Classification: Unclassified OS: All Reporter: arichardson.kde(a)gmail.com Hardware: Other Status: NEW Version: 10.0 Component: Drivers/DRI/R600 Product: Mesa The XServer randomly freezes for a few seconds or sometimes even 1-2 minutes. I cannot move the mouse, and the screen does not update. I have a HD4850 card running on a 3.12.6-1.g080d0df-desktop SMP PREEMPT x86_64 kernel with Mesa 10.0.1 (both from openSuSE packages). These freezes also happen with the default 3.11 kernel, I upgraded in the hope of it being fixed, but the issue is still present. These issues started after the upgrade to openSuSE 13.1 which has a 3.11 kernel instead of the previous 3.7 kernel. The Mesa version did not change, I was always running the latest released version. My guess is it has something to do with the r600 kernel changes in 3.8+. During these freeze periods I can ssh into my system and top shows no CPU usage, so the XServer seems to be sleeping instead of being in a busy loop. dmesg gives me no messages and /var/log/XOrg.0.log is also empty. I don't know how to get any more detailed logging output. If you provide me with the necessary environment variables/kernel parameters I will give you these logs. Not sure if this helps, but most of the time the freeze happens when I open a new tab in firefox or switch to a different one. However it also happens at random intervals using other programs. It can sometimes take quite a long time until this freeze happens, however once it has occured once, it usually happens again after a short timespan (1-2 minutes or even less). Is it possible to debug the XServer just like a normal program using gdb? If yes I will try to provide a useful backtrace once the next longer freeze happens -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 73504] New: Segfault in _save_Normal3fv running FlightGear
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=73504 Priority: medium Bug ID: 73504 Assignee: dri-devel(a)lists.freedesktop.org Summary: Segfault in _save_Normal3fv running FlightGear Severity: normal Classification: Unclassified OS: Linux (All) Reporter: nine(a)detonation.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 91869 --> https://bugs.freedesktop.org/attachment.cgi?id=91869&action=edit full konsole output of a session with a crash Running latest FlightGear git version on openSUSE 13.1 with Mesa-10.1~git20140110-1.1.x86_64, libLLVM35-3.5~svn20140107-1.1.x86_64, llvm-r600-3.5~svn20140107-1.1.x86_64, libdrm2-2.4.99~git20131225-1.2.x86_64 and kernel 3.13.0-rc7-6.g57a2f1c-desktop on a Radeon HD 5670 I get segfaults at seemingly random points. The backtrace always looks like this: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffebb61700 (LWP 10909)] 0x00007fffee1d5d23 in _save_Normal3fv (v=0x0) at vbo/vbo_attrib_tmp.h:340 340 vbo/vbo_attrib_tmp.h: No such file or directory. (gdb) bt #0 0x00007fffee1d5d23 in _save_Normal3fv (v=0x0) at vbo/vbo_attrib_tmp.h:340 #1 0x00007fffee0df589 in _ae_ArrayElement (elt=0) at main/api_arrayelt.c:1714 #2 0x00007fffee1cf690 in _save_OBE_DrawArrays (mode=<optimized out>, start=<optimized out>, count=<optimized out>) at vbo/vbo_save_api.c:1103 #3 0x00007ffff52ea0ed in osg::DrawArrays::draw(osg::State&, bool) const () from /opt/FlightGear/lib64/libosg.so.100 #4 0x00007ffff52341fa in osg::Geometry::drawImplementation(osg::RenderInfo&) const () from /opt/FlightGear/lib64/libosg.so.100 #5 0x00007ffff68b8780 in osg::Drawable::draw(osg::RenderInfo&) const () from /opt/FlightGear/lib64/libosgParticle.so.100 #6 0x00007ffff623ea98 in osgUtil::RenderLeaf::render(osg::RenderInfo&, osgUtil::RenderLeaf*) () from /opt/FlightGear/lib64/libosgUtil.so.100 #7 0x00007ffff623312c in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #8 0x00007ffff6232f2b in osgUtil::RenderBin::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #9 0x00007ffff6233436 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #10 0x00007ffff6244c13 in osgUtil::RenderStage::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #11 0x00007ffff6232f2b in osgUtil::RenderBin::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #12 0x00007ffff624352a in osgUtil::RenderStage::drawInner(osg::RenderInfo&, osgUtil::RenderLeaf*&, bool&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #13 0x00007ffff624446e in osgUtil::RenderStage::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /opt/FlightGear/lib64/libosgUtil.so.100 #14 0x00007ffff6253e4e in osgUtil::SceneView::draw() () from /opt/FlightGear/lib64/libosgUtil.so.100 #15 0x00007ffff5b02a14 in osgViewer::Renderer::draw() () from /opt/FlightGear/lib64/libosgViewer.so.100 #16 0x00007ffff5b03c2a in osgViewer::Renderer::operator()(osg::GraphicsContext*) () from /opt/FlightGear/lib64/libosgViewer.so.100 #17 0x00007ffff52698e1 in osg::GraphicsContext::runOperations() () from /opt/FlightGear/lib64/libosg.so.100 #18 0x00007ffff52740c9 in osg::RunOperations::operator()(osg::GraphicsContext*) () from /opt/FlightGear/lib64/libosg.so.100 #19 0x00007ffff5273a38 in osg::GraphicsOperation::operator()(osg::Object*) () from /opt/FlightGear/lib64/libosg.so.100 #20 0x00007ffff52dec8f in osg::OperationThread::run() () from /opt/FlightGear/lib64/libosg.so.100 #21 0x00007ffff527399e in osg::GraphicsThread::run() () from /opt/FlightGear/lib64/libosg.so.100 #22 0x00007ffff4c52bfc in OpenThreads::ThreadPrivateActions::StartThread(void*) () from /opt/FlightGear/lib64/libOpenThreads.so.13 #23 0x00007ffff77260db in start_thread () from /lib64/libpthread.so.0 #24 0x00007ffff206090d in clone () from /lib64/libc.so.6 Is this a bug in Mesa or more probably in FlightGear? -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 73480] New: Segmentation fault starting mpeg2 playback using XBMC
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=73480 Priority: medium Bug ID: 73480 Assignee: dri-devel(a)lists.freedesktop.org Summary: Segmentation fault starting mpeg2 playback using XBMC Severity: normal Classification: Unclassified OS: Linux (All) Reporter: doctor64(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 91830 --> https://bugs.freedesktop.org/attachment.cgi?id=91830&action=edit dmesg output When trying to play mpeg2 live TV stream in XBMC 13, using wsnipex ppa MESA and VDPAU, XBMC crashed. h264 streams using VDPAU play without problems. Disabling VDPAU in XBMC remove crash. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 73457] New: mpeg4 through vdpau randomly either correct or garbled (on same file!)
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=73457 Priority: medium Bug ID: 73457 Assignee: dri-devel(a)lists.freedesktop.org Summary: mpeg4 through vdpau randomly either correct or garbled (on same file!) Severity: normal Classification: Unclassified OS: All Reporter: adam(a)aphirst.karoo.co.uk Hardware: x86-64 (AMD64) Status: NEW Version: 10.0 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 91790 --> https://bugs.freedesktop.org/attachment.cgi?id=91790&action=edit mpv verbose log, when video decodes successfully This is somewhat difficult to explain. * AMD PALM E2-1800 APU * Arch Linux x86_64 * Kernel 3.12.6-ck (also with vanilla 3.12.6) * mesa 10.0.1, xf86-video-ati 7.2.0 One of the following three situations occurs, seemingly at random, when opening an mpeg4 video file using any player which supports vdpau hardware-decoding (e.g. mplayer r36498, VLC 2.1.2, mpv 0.3.2) 1. The video decodes and plays just fine 2. The video decodes incorrectly, with bright-green garbling, and general smearing 3. The video decodes and plays fine, BUT with a couple of small artefacts either in the player window, or anywhere on the screen (the artefacts are little black squares, inside which are a few fluorescent-coloured pixels flickering) The interesting point is that, on the same file, you can close and re-open the video player and receive a different random outcome each time. I'm in the habit of trying a few times to open my .avi videos until it "just works". This is not the same as the mpeg4 ASP garbling issue which I reported a month or so ago, which was 100% consistent on the affected files. For this bug, the files which display *this* problem are 'normal' mpeg4 videos, and whether or not decoding succeeds appears to be completely random. Frustratingly, neither the video player's verbose logs, nor the DPM messages in dmesg, indicate anything *at all* different between successful and unsuccessful attempts. I'll upload to this report a couple of log files, including the outputs of ffmpeg -i on a selection of affected files. I'll also upload some video samples, bear with me. -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 73444] New: wayland/weston EGL/GLESv2 - top portion of screen in fullscreen: vertices being clipped/flicker
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=73444 Priority: medium Bug ID: 73444 Assignee: dri-devel(a)lists.freedesktop.org Summary: wayland/weston EGL/GLESv2 - top portion of screen in fullscreen: vertices being clipped/flicker Severity: normal Classification: Unclassified OS: Linux (All) Reporter: emiettin(a)edu.lahti.fi Hardware: x86-64 (AMD64) Status: NEW Version: 10.0 Component: Drivers/Gallium/r600 Product: Mesa In fullscreen wayland/weston EGL/GLESv2 clients without X11 (as in weston launched from a tty), vertices ending up on the top 5-10% portion of the vertical screen space are being clipped (as in seemingly skipped altogether and disappearing), despite setting up an appropriate projection matrix + calling glViewport. This results in flickering sawtooth-like edges on the top of the screen area. This effect doesn't show up - in windowed mode - in screenshots (weston Super+s) - in screen capture (weston Super+r) - while zoomed in using the weston Super+mwheel shortcut, or - when using weston through X11. Asking about this on #dri-devel on Freenode lead to the following hypothesis by pq: 12:30 < pq> so if super+s, or zoom, or having it in a window makes the problem go away, then the fundamental difference is likely that when weston composites, everything goes well, but when weston tries to scan out the client image directly, something breaks. This occurs at least in mesa 9.2.x through git master. setup: Arch Linux x86_64 3.12.6-1, Radeon HD 5770 w/ {ati-dri, mesa, mesa-libgl}-9.2.5-1, -10.0.1-1, or -git wayland-1.3.0-1, weston-1.3.1-2 or git. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 73127] New: [r600g] Possible memory leak when playing WoW with CAICOS
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=73127 Priority: medium Bug ID: 73127 Assignee: dri-devel(a)lists.freedesktop.org Summary: [r600g] Possible memory leak when playing WoW with CAICOS Severity: normal Classification: Unclassified OS: Linux (All) Reporter: rankincj(a)googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 91298 --> https://bugs.freedesktop.org/attachment.cgi?id=91298&action=edit Message log showing page allocation failure I finally managed to build some libdrm-2.4.50 RPMs for Fedora 19 so that I could compile a recent -git snapshot. The HEAD commit was: author Alex Deucher <alexander.deucher(a)amd.com> 2013-12-24 20:22:31 (GMT) committer Alex Deucher <alexander.deucher(a)amd.com> 2013-12-24 20:22:31 (GMT) commit e2d53fac1c5b18f5c9e95d39d4e2be4703b0b363 (patch) (side-by-side diff) tree 51caa6afa79db9a733198f6bf5c6224c023fea2f parent 35a34143026785e015adb906756651807de89bde (diff) download mesa-e2d53fac1c5b18f5c9e95d39d4e2be4703b0b363.zip mesa-e2d53fac1c5b18f5c9e95d39d4e2be4703b0b363.tar.gz r600g: fix SUMO2 pci id 0x9649 is sumo2, not sumo. This resulted in an eventual crash of WoW and Minecraft, apparently due to memory exhaustion. (The messages log is attached). Reverting to my previous build seemed to fix things: author Marek Olšák <marek.olsak(a)amd.com> 2013-11-20 00:47:36 (GMT) committer Marek Olšák <marek.olsak(a)amd.com> 2013-11-23 00:54:57 (GMT) commit a3969aa125c8f61b093a5f5f69e8265a131051d0 (patch) (side-by-side diff) tree aaa0b9350231b29d9dd51c49c5c86e1fe78a6096 parent 46cf80fb366cb14827724a7fea004e81400cc602 (diff) download mesa-a3969aa125c8f61b093a5f5f69e8265a131051d0.zip mesa-a3969aa125c8f61b093a5f5f69e8265a131051d0.tar.gz mesa: initialize gl_renderbuffer::Depth in core -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 73088] New: Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up system after several minutes of use
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=73088 Priority: medium Bug ID: 73088 Assignee: dri-devel(a)lists.freedesktop.org Summary: Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up system after several minutes of use Severity: normal Classification: Unclassified OS: Linux (All) Reporter: appletorch(a)hotmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 91246 --> https://bugs.freedesktop.org/attachment.cgi?id=91246&action=edit Xorg.log Gone Home and Unigine Heaven 4.0 lock up my system after a few minutes of operation when using this ppa: https://launchpad.net/~oibaf/+archive/graphics-drivers/ When using mesa 9.2.1 provided in ubuntu 13.10 this does not occur with Gone Home. Same lock up issue happens when using ubuntu 14.04 development with mesa 10.0.1. In all cases I had radeon.audio=1, radeon.dpm=1, and R600_DEBUG=sb. -- You are receiving this mail because: You are the assignee for the bug.

1 13

[Bug 72732] New: Missing NULL check; radeon_drm_winsys.c
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=72732 Priority: medium Bug ID: 72732 Assignee: dri-devel(a)lists.freedesktop.org Summary: Missing NULL check; radeon_drm_winsys.c Severity: normal Classification: Unclassified OS: All Reporter: freedesktop(a)treblig.org Hardware: Other Status: NEW Version: unspecified Component: Drivers/DRI/R600 Product: Mesa I can sometime trigger a seg in do_winsys_init at radeon_drm_winsys.c on my HD4350 There seems to be a simple missing NULL check: 214 version = drmGetVersion(ws->fd); 215 if (version->version_major != 2 || 216 version->version_minor < 3) { All the other users of drmGetVersion do a NULL check, so I suggest adding: if (!version) { fprintf(stderr,"%s: drmGetVersion NULL - bad fd (%d)?\n", __FUNCTION__, ws->fd); return FALSE; } I believe this to be part of the reason for: https://bugzilla.redhat.com/show_bug.cgi?id=993463 why drmGetVersion is failing is a different matter (probably a bad fd at that point - but why?) , but at least the NULL check would stop the seg. Dave -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 72699] New: [llvm] Europa Universalis 4 closes its window and eats all memory while loading
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=72699 Priority: medium Bug ID: 72699 Assignee: dri-devel(a)lists.freedesktop.org Summary: [llvm] Europa Universalis 4 closes its window and eats all memory while loading Severity: normal Classification: Unclassified OS: All Reporter: nikoamia(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Hello, While using new llvm from svn (rev. 197173) Europa Universalis 4 closes its window on "Loading Graphics" stage but retains as process and eats up all memory and swap, so it is needed to kill it manually. Problem disappears after reverting to rev. 196300. Kernel: 3.12.5, was also tested on earlier Mesa: git 60139.40070e7 Video: Mobility Radeon HD 5650M -- You are receiving this mail because: You are the assignee for the bug.

1 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2015