dri-devel September 2014

dri-devel@lists.freedesktop.org

173 participants
1045 discussions

[Bug 77835] New: X crash when using xrandr with R9 290X and 7870 for triple head
by bugzilla-daemon＠freedesktop.org 18 Jan '16

18 Jan '16

https://bugs.freedesktop.org/show_bug.cgi?id=77835 Priority: medium Bug ID: 77835 Assignee: dri-devel(a)lists.freedesktop.org Summary: X crash when using xrandr with R9 290X and 7870 for triple head Severity: major Classification: Unclassified OS: Linux (All) Reporter: mbroemme(a)libmpq.org Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 97831 --> https://bugs.freedesktop.org/attachment.cgi?id=97831&action=edit Xorg log of crash I'm trying to get a system with a R9 290X and a HD 7870 GHz Edition working. If I use the cards independently everything works fine under X (the 7870 works with glamor acceleration and the R9 290X without acceleration) but the problem is to get them working together with single X. Attached is my Xorg.0.log and the dmesg output. I'm using the following cards: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT [Radeon HD 8970] 04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn XT [Radeon HD 7870 GHz Edition] Steps to reproduce this issue: #1 startx #2 xrandr --output DVI-0 --primary #3 xrandr --output HDMI-1 --right-of DVI-0 #4 xrandr --setprovideroutputsource 1 0 #5 xrandr --output HDMI-1-0 --mode 1920x1080 --right-of HDMI-1 Right now X is crashed with the following: (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x48) [0x584b08] (EE) 1: /usr/bin/X (0x400000+0x1887f9) [0x5887f9] (EE) 2: /usr/lib/libpthread.so.0 (0x7f2a182c8000+0xf880) [0x7f2a182d7880] (EE) (EE) Segmentation fault at address 0x0 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. (EE) (II) AIGLX: Suspending AIGLX clients for VT switch (EE) Server terminated with error (1). Closing log file. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 4790 requests (4790 known processed) with 9 events remaining. xinit: connection to X server lost The system is running Arch Linux with the following configuration: ati-dri 10.1.1 glamor-egl 0.6.0 libdrm 2.4.53 linux 3.14.1 linux-firmware 20140316.dec41bc mesa 10.1.1 mesa-libgl 10.1.1 xf86-video-ati 7.3.0 xorg-server 1.15.1 Does anybody has a hint what I could try next? Also what is needed to get acceleration working. I tried it with "NoAccel" "False" and "AccelMethod" "glamor" but it just freezes my X on startup. :) --Maik -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 80868] New: Support screen scaling modes for external monitors
by bugzilla-daemon＠freedesktop.org 07 Jan '16

07 Jan '16

https://bugs.freedesktop.org/show_bug.cgi?id=80868 Priority: medium Bug ID: 80868 Assignee: dri-devel(a)lists.freedesktop.org Summary: Support screen scaling modes for external monitors Severity: enhancement Classification: Unclassified OS: All Reporter: kamil.paral(a)gmail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI As we steadily progress into the year of Linux gaming, there will be many requests regarding games. This is one of them :) Currently, it is possible to set scaling mode for a monitor only if the monitor is internal (LVDS, eDP). This is done through xrandr: $ xrandr --prop Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192 LVDS1 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm <snip> scaling mode: Full aspect supported: None, Full, Center, Full aspect <snip> $ xrandr --output LVDS1 --set "scaling mode" "Center" However, it is not possible to do this for external panels (VGA, DVI, HDMI, DP). The "scaling mode" property is not exported for these panels (this was confirmed to me by ckoenig and agd5f on the #radeon irc channel, many thanks). Please allow users to set scaling mode even for external panels. There are many use cases for it, mainly related to gaming. Note: Many panels provide options to do the scaling on their own, however, only the very expensive ones provide good options. For example, the majority of "mainstream" panels don't provide the "center" scaling mode - however, that is very useful when playing older lower-resolution games when you prefer smaller and sharp image instead of larger and blurry. Second example are certain panels which support "full aspect" mode only for a small selection or resolutions, otherwise they simply scale to "full" ignoring image aspect ratio. For these panels, GPU scaling is essential if the user doesn't want to see distorted aspect ratio image. My personal use case is buying BenQ BL2411PT 1920x1200 panel, which *can not* display 1920x1080 resolution with correct aspect ratio - it always stretches it vertically. Yes, it's very dumb, yet that's how modern panels commonly work (and not just the cheap ones). This hasn't been a large issue in the past, because we had no games and opensource drivers were hardly able to run them anyway. Both things are changing rapidly. The proprietary AMD and NVIDIA drivers have been offering GPU scaling functionality for a long time, both on Linux and Windows. Here's an example of their GUI configuration: https://www.codeweavers.com/support/wiki/linux/faq/43_game_stretch Please allow us to use GPU scaling even with radeon driver. Thank you. There has been some technical details on the IRC, it is linked here: http://paste.fedoraproject.org/115407/ It seems to me that this functionality could be implemented in a simple and straightforward way: a) provide a single configuration option - "scaling mode" b) on internal panels default to "Full aspect" (which you already do) - that is reasonable default, because these panels have no control buttons c) on external panels default to "None" - that allows the user to easily configure scaling through the panel. Only if the user is dissatisfied, he/she can enable GPU scaling through xrandr. And here's one more user seconding my thoughts on the IRC: AbortRetryFail: 1:1 unscaled output for LCDs would be awesome. AbortRetryFail: 1280x720 looks horrible scaled up to fit a 1366x768 LCD Thanks. -- You are receiving this mail because: You are the assignee for the bug.

1 21

[Bug 64661] New: udl causes blank screen
by bugzilla-daemon＠bugzilla.kernel.org 30 Dec '15

30 Dec '15

https://bugzilla.kernel.org/show_bug.cgi?id=64661 Bug ID: 64661 Summary: udl causes blank screen Product: Drivers Version: 2.5 Kernel Version: 3.11.6+ 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: jason(a)schulz.name Regression: No Using the modesetting driver for X, udl no longer outputs a video signal. This behavior is present in at least 3.11.6, and 3.12.0. The last known version the behavior was what I would normally expect was 3.10.17. -- You are receiving this mail because: You are watching the assignee of the bug.

1 11

[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 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 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2014