dri-devel May 2015

dri-devel@lists.freedesktop.org

191 participants
1132 discussions

[Bug 39287] New: Framebuffer object extension is exposed, but appears never supported by radeon on R200
by bugzilla-daemon＠freedesktop.org 01 Dec '15

01 Dec '15

https://bugs.freedesktop.org/show_bug.cgi?id=39287 Summary: Framebuffer object extension is exposed, but appears never supported by radeon on R200 Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: b7.10110111(a)gmail.com Created an attachment (id=49182) --> (https://bugs.freedesktop.org/attachment.cgi?id=49182) Test program See test program. A framebuffer object is created there, and a color attachment of 2^n x 2^m is attached to it. Regardless of using depth renderbuffer attachment, framebuffer status is always GL_FRAMEBUFFER_UNSUPPORTED. Test program continues execution nonetheless, to see if something is drawn. In some circumstances, i do see some part of the image for several frames, but they disappear after that. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 44568] New: Half-Life 1 engine has poor fps is large areas
by bugzilla-daemon＠freedesktop.org 26 Nov '15

26 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=44568 Bug #: 44568 Summary: Half-Life 1 engine has poor fps is large areas Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: toni.spets(a)iki.fi Created attachment 55280 --> https://bugs.freedesktop.org/attachment.cgi?id=55280 Slow GLTrace I've been following the fps of this engine for a few years, pre-gallium and lately gallium. There is a noticable fps drop in maps that contain water or a lot of models. Normally, a fps drop from 100 to ~15 happens in action situations with smoke, other players, water etc. Taken that the engine is over 10 years old, is using standard OpenGL and it runs very fine at 100fps on windows, my guesstimate is that it is using some unoptimized GL path. Attached slow gltrace is from viewing an area where my fps in 800x600 resolution is around 56 with a lot of models on the screen and the fast trace is from a map that doesn't have that drop at all when nothing is happening. The traces are around from the same period of time but the fast trace went at ~25 fps and the slow at ~5 fps when it was logged. Both traces start and end with the game menu but only briefly. Would appreciate if someone could finally take a shot at fixing this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[Bug 96361] New: [Bisected, radeon]Non-infinite boot loop since v3.13
by bugzilla-daemon＠bugzilla.kernel.org 24 Nov '15

24 Nov '15

https://bugzilla.kernel.org/show_bug.cgi?id=96361 Bug ID: 96361 Summary: [Bisected, radeon]Non-infinite boot loop since v3.13 Product: Drivers Version: 2.5 Kernel Version: 3.19 Hardware: x86-64 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: servuswiegehtz(a)yahoo.de Regression: No For a while now my desktop pc experiences boot issues. I try to boot and after grub the screen just goes in standby mode and sometimes it reboots and sometimes just nothing happens. After a few tries it usually succeeds in booting. So I bisected the kernel and this is the first bad commit: 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 Steps to reproduce: not sure, seems to be a rare bug. install a linux kernel newer than 3.13 and boot Hardware: AMD Phenom X4 955 AMD 5770 (Evergreen, Juniper) I tried to get a log from systemd (journalctl --boot=-1) but there is none for the failed boot attempt. -- You are receiving this mail because: You are watching the assignee of the bug.

1 6

[Bug 73528] New: Deferred lighting in Second Life causes system hiccups and screen flickering
by bugzilla-daemon＠freedesktop.org 24 Nov '15

24 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=73528 Priority: medium Bug ID: 73528 Assignee: dri-devel(a)lists.freedesktop.org Summary: Deferred lighting in Second Life causes system hiccups and screen flickering Severity: major Classification: Unclassified OS: Linux (All) Reporter: sonichedgehog_hyperblast00(a)yahoo.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa I compiled Mesa with libdrm from their GIT repositories (10.1, commit 2dc35a619c50139d07ad96fc4dfe456e5811c84e). I started up the Second Life viewer through it (Kokua x64, 3.6.12.30743, Dec 12 2013 05:51:00) and logged in. Upon enabling Advanced Lighting Model from Preferences - Graphics, the system froze and the screen started flickering, turning black then recovering every few seconds. The scene also got covered in pink pixels, meaning it also failed to render correctly. I was barely able to move the mouse pointer and shut the viewer down. Once I did, everything returned to normal. This does not happen with Mesa 9.2.3, and other Graphics options in the viewer work fine (like "Basic shaders" or "Atmospheric shaders"). Shadows were disabled and likely not a cause. If someone has Second Life, please try the deferred lighting system under the 10.1 development version of Mesa. Currently, I don't have any more information on the problem apart from having experienced the described symptoms. -- You are receiving this mail because: You are the assignee for the bug.

1 46

[Bug 82109] New: Firefox crashes Google Maps, likely related to graphics driver
by bugzilla-daemon＠freedesktop.org 24 Nov '15

24 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=82109 Priority: medium Bug ID: 82109 Assignee: dri-devel(a)lists.freedesktop.org Summary: Firefox crashes Google Maps, likely related to graphics driver Severity: normal Classification: Unclassified OS: Linux (All) Reporter: markus.popp(a)gmx.at Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa My Firefox (31.0 release to 34.0 nightly) on Linux64 regularly crashes when accessing Google Maps. First time during a session it works fine, but going back to Google Maps at a later point during the same session crashes Firefox. I filed a bug at Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1022987 but since the crashes are apparently caused by the graphics driver, as developers told me, I was asked to file a bug report here. Find a corresponding Firefox Crash Report at https://crash-stats.mozilla.com/report/index/228c877e-9bdf-4a59-b043-e51592… Please let me know if I can assist with providing further information. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 76840] New: HybridGraphics: Kernel driver in use: radeon but adapter not listed
by bugzilla-daemon＠freedesktop.org 20 Nov '15

20 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=76840 Priority: medium Bug ID: 76840 Assignee: dri-devel(a)lists.freedesktop.org Summary: HybridGraphics: Kernel driver in use: radeon but adapter not listed Severity: normal Classification: Unclassified OS: Linux (All) Reporter: xanto(a)egaming.ro Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 96665 --> https://bugs.freedesktop.org/attachment.cgi?id=96665&action=edit xorg.conf , Xorg.0.log - intel device, Xorg.0.log - radeon device, Xorg.1.log intel device, lspci , dmesg, inxi, glxinfo, xrandr, fglrx Xorg.1.log Hello, I'm using a Dell Inspiron Laptop Model 3537 with latest manufacturer BIOS update and firmware-addon-dell installed. Hardware consists of an Intel i5-4200U (HD4400) + AMD Radeon HD 8670M. I've tried latest Linux Mint Live/Install ISO, but xserver won't start unless I unload radeon module. After latest software stack upgrade (kernel 3.14 + oibaf ppa https://launchpad.net/~oibaf/+archive/graphics-drivers [mesa10.2-git, ati-1.7.3-git]), system boots fine, dmesg seems fine: dmesg | egrep "radeon|drm" [ 2.448474] [drm] Initialized drm 1.1.0 20060810 [ 2.478265] [drm] Memory usable by graphics device = 2048M [ 2.478273] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver [ 2.496049] [drm] radeon kernel modesetting enabled. [ 2.496127] radeon 0000:03:00.0: enabling device (0006 -> 0007) [ 2.525982] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 2.525983] [drm] Driver supports precise vblank timestamp query. [ 2.655140] fbcon: inteldrmfb (fb0) is primary device [ 4.169021] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 4.173215] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 4.176558] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 4.176955] [drm] initializing kernel modesetting (HAINAN 0x1002:0x6660 0x1028:0x05EA). [ 4.177008] [drm] register mmio base: 0xC0500000 [ 4.177009] [drm] register mmio size: 262144 [ 4.538007] radeon 0000:03:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) [ 4.538009] radeon 0000:03:00.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF [ 4.538010] [drm] Detected VRAM RAM=1024M, BAR=256M [ 4.538011] [drm] RAM width 64bits DDR [ 4.538115] [drm] radeon: 1024M of VRAM memory ready [ 4.538116] [drm] radeon: 1024M of GTT memory ready. [ 4.538129] [drm] Loading HAINAN Microcode [ 4.538241] [drm] Internal thermal controller without fan control [ 4.538304] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 4.546378] [drm] radeon: dpm initialized [ 4.546382] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 4.547031] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 4.547036] [drm] PCIE gen 2 link speeds already enabled [ 4.548758] [drm] PCIE GART of 1024M enabled (table at 0x0000000000040000). [ 4.548860] radeon 0000:03:00.0: WB enabled [ 4.548863] radeon 0000:03:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880035ab0c00 [ 4.548865] radeon 0000:03:00.0: fence driver on ring 1 use gpu addr 0x0000000040000c04 and cpu addr 0xffff880035ab0c04 [ 4.548866] radeon 0000:03:00.0: fence driver on ring 2 use gpu addr 0x0000000040000c08 and cpu addr 0xffff880035ab0c08 [ 4.548867] radeon 0000:03:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff880035ab0c0c [ 4.548869] radeon 0000:03:00.0: fence driver on ring 4 use gpu addr 0x0000000040000c10 and cpu addr 0xffff880035ab0c10 [ 4.548871] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 4.548871] [drm] Driver supports precise vblank timestamp query. [ 4.548895] radeon 0000:03:00.0: irq 63 for MSI/MSI-X [ 4.548906] radeon 0000:03:00.0: radeon: using MSI. [ 4.548930] [drm] radeon: irq initialized. [ 4.745915] [drm] ring test on 0 succeeded in 1 usecs [ 4.745921] [drm] ring test on 1 succeeded in 1 usecs [ 4.745926] [drm] ring test on 2 succeeded in 1 usecs [ 4.745988] [drm] ring test on 3 succeeded in 2 usecs [ 4.745996] [drm] ring test on 4 succeeded in 1 usecs [ 4.747414] [drm] ib test on ring 0 succeeded in 0 usecs [ 4.747443] [drm] ib test on ring 1 succeeded in 0 usecs [ 4.747467] [drm] ib test on ring 2 succeeded in 0 usecs [ 4.747489] [drm] ib test on ring 3 succeeded in 0 usecs [ 4.747513] [drm] ib test on ring 4 succeeded in 1 usecs [ 4.747825] [drm] Radeon Display Connectors [ 4.747835] radeon 0000:03:00.0: No connectors reported connected with modes [ 4.747837] [drm] Cannot find any crtc or sizes - going 1024x768 [ 4.750180] [drm] fb mappable at 0xA1250000 [ 4.750181] [drm] vram apper at 0xA0000000 [ 4.750182] [drm] size 3145728 [ 4.750183] [drm] fb depth is 24 [ 4.750184] [drm] pitch is 4096 [ 4.750269] radeon 0000:03:00.0: fb1: radeondrmfb frame buffer device [ 4.751709] [drm] Initialized radeon 2.37.0 20080528 for 0000:03:00.0 on minor 1 However, xrandr, inxi and glxinfo (noone except lspci) won't show the radeon device. Starting X with device configured as radeon, crashes with the error (EE) no screens found(EE) LIBGL_DEBUG=verbose DRI_PRIME=0 glxgears libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so libGL: Can't open configuration file /root/.drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 305 frames in 5.0 seconds = 60.952 FPS 301 frames in 5.0 seconds = 60.000 FPS LIBGL_DEBUG=verbose DRI_PRIME=1 glxgears libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so libGL: Can't open configuration file /root/.drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 36463 frames in 5.0 seconds = 7292.515 FPS 35941 frames in 5.0 seconds = 7188.027 FPS 35969 frames in 5.0 seconds = 7193.778 FPS 35990 frames in 5.0 seconds = 7197.914 FPS 36353 frames in 5.0 seconds = 7270.465 FPS 36544 frames in 5.0 seconds = 7308.674 FPS 36281 frames in 5.0 seconds = 7256.154 FPS mike-g337 tmp # DRI_PRIME=0 glxinfo | grep 'OpenGL render' OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile mike-g337 tmp # DRI_PRIME=1 glxinfo | grep 'OpenGL render' OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile Attached is a file containing: xorg.conf Xorg.0.log - intel device Xorg.0.log - radeon device Xorg.1.log intel device lspci -kvvv dmesg inxi -G glxinfo xrandr --listproviders fglrx Xorg.1.log Hope it helps. Thank you in advance, Mike. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[PATCH 0/9] drm: More vblank on/off work
by ville.syrjala＠linux.intel.com 19 Nov '15

19 Nov '15

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Another vblank series with the following features: - Plug a race between drm_vblank_off() and marking the crtc inactive - Don't send zeroed vblank evens to userspace at drm_vblank_off() - Have the user visible vblank counter account the entire time when the crtc was active, regardless of how long vblank interrupts were enabled - Avoid random jumps in the user visible vblank counter if the hardware counter gets reset - Allow disabling vblank interrupts immediately at drm_vblank_put() - Some polish via coccinelle While setting drm_vblank_offdelay to 0 is now possible, I'm not sure if we should set it 0 automatically in the i915 driver. If there are multiple GPUs in the system that setting will affect them all, which might have bad consequences if the other GPU doesn't have a hardware frame counter, or if it's just buggy. So perhaps we should move that option to be per-driver? Ville Syrjälä (9): drm: Always reject drm_vblank_get() after drm_vblank_off() drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off() drm: Don't clear vblank timestamps when vblank interrupt is disabled drm: Move drm_update_vblank_count() drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off() drm: Avoid random vblank counter jumps if the hardware counter has been reset drm: Disable vblank interrupt immediately when drm_vblank_offdelay==0 drm: Reduce the amount of dev->vblank[crtc] in the code drm/i915: Leave interrupts enabled while disabling crtcs during suspend Documentation/DocBook/drm.tmpl | 1 + drivers/gpu/drm/drm_irq.c | 285 +++++++++++++++++++------------- drivers/gpu/drm/drm_stub.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 +- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/intel_display.c | 15 ++ include/drm/drmP.h | 2 +- 7 files changed, 192 insertions(+), 120 deletions(-) -- 1.8.5.5

7 43

[Bug 88043] Star Conflict locks up AMD BARTS
by bugzilla-daemon＠freedesktop.org 19 Nov '15

19 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=88043 Bug ID: 88043 Summary: Star Conflict locks up AMD BARTS Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: EoD(a)xmw.de Created attachment 111753 --> https://bugs.freedesktop.org/attachment.cgi?id=111753&action=edit dmesg output during the lockup Every time I am trying to start the free-to-play game "Star Conflict" via Steam it locks up as soon as a match has been started. I was only able to shutdown the computer via ssh, no input device did work. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 36782] New: textures on Earth in Celestia contain pixels from other windows
by bugzilla-daemon＠freedesktop.org 17 Nov '15

17 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=36782 Summary: textures on Earth in Celestia contain pixels from other windows Product: Mesa Version: 7.10 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: acelists(a)atlas.sk Created an attachment (id=46261) --> (https://bugs.freedesktop.org/attachment.cgi?id=46261) See the blue dotted band around the planet - it is a window titlebar. Textures on the planet Earth are rendered garbled with data pixel taken from other windows (programs), probably taken from released GPU memory. Note it only happens on Earth. The garbled texture is not the planet surface one, but it is the clouds layer. That is loaded from a file that is 1024x512. It does not happen when lowres textures are selected. Then a 128x64px file is used for the clouds. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 8

[Bug 84662] New: Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU
by bugzilla-daemon＠freedesktop.org 05 Nov '15

05 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=84662 Bug ID: 84662 Summary: Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com R9270X PCIE 2.0 2 gig vram 4 gig ram. Unreal demo Elemental only recently started working with git llvm/mesa, do no bisection done on these. The demo even when working is very broken - constant 1/4 sec stutters with a couple of 1/2 - 1 sec. But after - commit 4439d469706699b4e69ef410ebc9115339f6e9e6 Author: Michel Dänzer <michel.daenzer(a)amd.com> Date: Thu Jul 31 18:43:49 2014 +0900 drm/radeon: Always flush the HDP cache before submitting a CS to the GPU This ensures the GPU sees all previous CPU writes to VRAM, which makes it safe: * For userspace to stream data from CPU to GPU via VRAM instead of GTT * For IBs to be stored in VRAM instead of GTT * For ring buffers to be stored in VRAM instead of GTT, if the HPD flush is performed via MMIO There are far longer pauses of many seconds - run time to unreal logo on "good" is 3:45 on bad best 5:39 can be longer. Screens to be attached show quite different vram/gtt usage between good and bad. Related to https://bugs.freedesktop.org/show_bug.cgi?id=82050 I bisected to the same commit in that bug, but applying the mesa patch https://bugs.freedesktop.org/show_bug.cgi?id=82050#c19 doesn't help here. CONFIG_CMA is not set. Tried kernel org 3.17-rc7 as it was reported in above as working, but not for me. -- You are receiving this mail because: You are the assignee for the bug.

1 58

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2015