dri-devel August 2012

dri-devel@lists.freedesktop.org

145 participants
811 discussions

[Bug 29318] New: Marbleblast textures broken on r600
by bugzilla-daemon＠freedesktop.org 04 Nov '12

04 Nov '12

https://bugs.freedesktop.org/show_bug.cgi?id=29318 Summary: Marbleblast textures broken on r600 Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: akirchhoff135014(a)comcast.net On some levels the textures in marbleblast are washed out. The demo is available here: http://www.torquepowered.com/products/download/15 You can see this on intermediate level 24. Mesa is from git: 2.0 Mesa 7.9-devel. Happens with both KMS and UMS. Works fine with both r300 and fglrx. -- 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 28359] New: Regression running Second Life viewer on r600 (mipmap generation issue?)
by bugzilla-daemon＠freedesktop.org 02 Nov '12

02 Nov '12

https://bugs.freedesktop.org/show_bug.cgi?id=28359 Summary: Regression running Second Life viewer on r600 (mipmap generation issue?) Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: makosoft(a)googlemail.com There's a regression in recent git master when running the Second Life viewer on the r600 driver. Objects flash in and out of existence continuously, making Second Life unusable. git bisect points to the commit 055750fafba58fd2ee0f5611b566a71ab0f22984 "Enable hardware mipmap generation for radeon" on the 24th of May, which is plausible since Second Life generates all mipmaps at runtime. I'm using a 2600XT card, Linux 2.6.34, latest libdrm master, and the latest unofficial Imprudence client release (since the official client isn't available in an x86_64 version). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 6

[Bug 32323] New: GL_EXT_texture_sRGB is broken
by bugzilla-daemon＠freedesktop.org 02 Nov '12

02 Nov '12

https://bugs.freedesktop.org/show_bug.cgi?id=32323 Summary: GL_EXT_texture_sRGB is broken Product: Mesa Version: 7.9 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: marlam(a)marlam.de The GL extension GL_EXT_texture_sRGB defines the texture formats GL_SRGB and friends and specifies that sampling such a texture automatically converts the values from non-linear RGB (sRGB) to linear RGB. However, this conversion is not performed on my system; the textures seem to be sampled as if they were normal GL_RGB textures. This results in wrong colors (e.g. in the git version of the Bino 3D video player: far too bright). I'm running Ubuntu 10.10 on x86_64 and get the following version info from GL: OpenGL version: 2.1 Mesa 7.9-devel OpenGL renderer: Mesa DRI R600 (RV710 954F) 20090101 TCL DRI2 OpenGL vendor: Advanced Micro Devices, Inc. If you need more information, please let me know. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 40931] New: r600g: interpret integer texture types as ints regresses VDPAU/XVMC decode.
by bugzilla-daemon＠freedesktop.org 02 Nov '12

02 Nov '12

https://bugs.freedesktop.org/show_bug.cgi?id=40931 Summary: r600g: interpret integer texture types as ints regresses VDPAU/XVMC decode. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: lists(a)andyfurniss.entadsl.com Using rv790 grey is rendered with VDPAU/XVMC decode since commit f2bae9456f141f8c1104ef2a0aab31f6190ae5f0 Author: Dave Airlie <airlied(a)redhat.com> Date: Thu Sep 15 12:41:00 2011 +0100 r600g: interpret integer texture types as ints. For signed/unsigned with no normalisation or srgb, assume its an INT type texture. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 9

[Bug 49632] New: radeon: The kernel rejected CS,
by bugzilla-daemon＠freedesktop.org 02 Nov '12

02 Nov '12

https://bugs.freedesktop.org/show_bug.cgi?id=49632 Bug #: 49632 Summary: radeon: The kernel rejected CS, Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: execute.method(a)gmail.com Created attachment 61215 --> https://bugs.freedesktop.org/attachment.cgi?id=61215 glxgears apitrace 5-8-12 glxgears: radeon: The kernel rejected CS, see dmesg for more information. chromium --enable-webgl --ignore-gpu-blacklist: radeon: The kernel rejected CS, see dmesg for more information. EE r600_pipe.c:78 r600_create_fence - r600: too many concurrent fences dmesg output: [ 1306.131363] radeon 0000:01:00.0: forbidden register 0x00028354 at 166 [ 1306.131366] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Computer Info: Linux 3.3.4-2-ARCH 0.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730XT [Radeon HD 4670] model name : AMD FX(tm)-6100 Six-Core Processor cpu MHz : 4013.411 model name : AMD FX(tm)-6100 Six-Core Processor cpu MHz : 4013.411 model name : AMD FX(tm)-6100 Six-Core Processor cpu MHz : 4013.411 model name : AMD FX(tm)-6100 Six-Core Processor cpu MHz : 4013.411 model name : AMD FX(tm)-6100 Six-Core Processor cpu MHz : 4013.411 model name : AMD FX(tm)-6100 Six-Core Processor cpu MHz : 4013.411 X.Org version: 1.12.1 dimensions: 1920x1080 pixels (508x285 millimeters) depth of root window: 24 planes direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 -- OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 8.1-devel OpenGL shading language version string: 1.30 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, Mesa and DDX built from git, tested for a few weeks (I'm a busy man). Started when updated/rebuilt on 4-18-12. Built again on 5-6-12. Official packages work. Reproduciblility: Permanent Similar to/Same as: https://bugs.freedesktop.org/show_bug.cgi?id=47039 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 12

[Bug 48455] New: Enabling R600_STREAMOUT causes graphical corruption
by bugzilla-daemon＠freedesktop.org 02 Nov '12

02 Nov '12

https://bugs.freedesktop.org/show_bug.cgi?id=48455 Bug #: 48455 Summary: Enabling R600_STREAMOUT causes graphical corruption Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: me(a)BaloneyGeek.com I use Mesa from Git (on an Arch Linux box), and build a new copy weekly. Since the last two weeks, keeping R600_STREAMOUT enabled in my /etc/environment file leads to severe graphical corruption (the screen is completely garbled), making it unusable on my Gnome 3 based system. Both GDM and GNOME-Shell exhibit this corruption, making it impossible to conduct tests on the system. Here are some relevant outputs: /etc/environment: LIBGL_DRIVERS_PATH=/opt/mesa-master/lib/xorg/modules/dri VDPAU_DRIVER=r600 R600_GLSL130=1 #R600_STREAMOUT=1 Keeping the last line enabled causes issues. Also, uname -a: Linux bg14ina-laptop 3.3.1-2-ck #1 SMP PREEMPT Thu Apr 5 18:01:36 EDT 2012 x86_64 Intel(R) Core(TM)2 Duo CPU T6670 @ 2.20GHz GenuineIntel GNU/Linux glxinfo | grep -i opengl: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV710 OpenGL version string: 2.1 Mesa 8.1-devel (git-c653287) OpenGL shading language version string: 1.30 Relevant line from lspci:01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV710 [Mobility Radeon HD 4300 Series] The card is a 512 MB ATI Mobility Radeon HD4330, (VID:PID = 1002:9552) Other software versions are: xorg-server 1.12.0.901-1 xf86-video-ati 6.14.4-2 libdrm 2.4.33-1 libtxc_dxtn 1.0.1-2 The flags to configure when building Mesa from git: ./configure --prefix=/opt/mesa-master --with-dri-driverdir=/opt/mesa-master/lib/xorg/modules/dri --with-gallium-drivers=r300,r600,swrast --with-dri-drivers=swrast --enable-texture-float --enable-glx-tls --enable-xcb --enable-shared-dricore --enable-gbm --enable-gallium-gbm --enable-xvmc --enable-vdpau --enable-gallium-g3dvl --enable-osmesa --enable-xorg --enable-shared-glapi --enable-gles1 --enable-gles2 --enable-openvg --enable-gallium-egl If there's anything else I can post, please let me know. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 36965] New: GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken
by bugzilla-daemon＠freedesktop.org 02 Nov '12

02 Nov '12

https://bugs.freedesktop.org/show_bug.cgi?id=36965 Summary: GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken Product: Mesa Version: 7.10 Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: marlam(a)marlam.de The GL extension GL_EXT_texture_sRGB (which is in OpenGL 2.1 core) defines the texture formats GL_SRGB and friends and specifies that sampling such a texture automatically converts the values from non-linear RGB (sRGB) to linear RGB. However, this conversion is not performed; the textures are sampled as if they were normal GL_RGB textures. This results in wrong colors (e.g. in the Bino 3D video player: far too bright). I'm running Ubuntu 11.04 on x86_64 and get the following version info from GL: OpenGL version: 2.1 Mesa 7.10.2 OpenGL renderer: Gallium 0.4 on AMD RV710 OpenGL vendor: X.Org If you need more information, please let me know. [This is the same as bug 32323, but re-reported for newer Mesa versions] -- 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 50422] New: Furmark.exe crash with wine (32 bits under 64 bits) with llvm-3.1 and r600-llvm-compiler enabled
by bugzilla-daemon＠freedesktop.org 31 Oct '12

31 Oct '12

https://bugs.freedesktop.org/show_bug.cgi?id=50422 Bug #: 50422 Summary: Furmark.exe crash with wine (32 bits under 64 bits) with llvm-3.1 and r600-llvm-compiler enabled Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: lordheavym(a)gmail.com Created attachment 62162 --> https://bugs.freedesktop.org/attachment.cgi?id=62162 wine output and backtrace * glxinfo32: OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 2.1 Mesa 8.1-devel (git-6404095) OpenGL shading language version string: 1.30 * uname -a Linux archMain 3.4.0-1-ARCH #1 SMP PREEMPT Mon May 21 10:10:13 CEST 2012 x86_64 GNU/Linux -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 14

[RFC 0/5] Generic panel framework
by Laurent Pinchart 31 Oct '12

31 Oct '12

Hi everybody, While working on DT bindings for the Renesas Mobile SoC display controller (a.k.a. LCDC) I quickly realized that display panel implementation based on board code callbacks would need to be replaced by a driver-based panel framework. Several driver-based panel support solution already exist in the kernel. - The LCD device class is implemented in drivers/video/backlight/lcd.c and exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV API for historical reason, uses board code callback for reset and power management, and doesn't include support for standard features available in today's "smart panels". - OMAP2+ based systems use custom panel drivers available in drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display controller) specific APIs. - Similarly, Exynos based systems use custom panel drivers available in drivers/video/exynos. Only a single driver (s6e8ax0) is currently available. That driver is based on Exynos display controller specific APIs and on the LCD device class API. I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus Lorentzon (working on panel support for ST/Linaro), and we agreed that a generic panel framework for display devices is needed. These patches implement a first proof of concept. One of the main reasons for creating a new panel framework instead of adding missing features to the LCD framework is to avoid being tied to the FBDEV framework. Panels will be used by DRM drivers as well, and their API should thus be subsystem-agnostic. Note that the panel framework used the fb_videomode structure in its API, this will be replaced by a common video mode structure shared across subsystems (there's only so many hours per day). Panels, as used in these patches, are defined as physical devices combining a matrix of pixels and a controller capable of driving that matrix. Panel physical devices are registered as children of the control bus the panel controller is connected to (depending on the panel type, we can find platform devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ... devices). The generic panel framework matches registered panel devices with panel drivers and call the panel drivers probe method, as done by other device classes in the kernel. The driver probe() method is responsible for instantiating a struct panel instance and registering it with the generic panel framework. Display drivers are panel consumers. They register a panel notifier with the framework, which then calls the notifier when a matching panel is registered. The reason for this asynchronous mode of operation, compared to how drivers acquire regulator or clock resources, is that the panel can use resources provided by the display driver. For instance a panel can be a child of the DBI or DSI bus controlled by the display device, or use a clock provided by that device. We can't defer the display device probe until the panel is registered and also defer the panel device probe until the display is registered. As most display drivers need to handle output devices hotplug (HDMI monitors for instance), handling panel through a notification system seemed to be the easiest solution. Note that this brings a different issue after registration, as display and panel drivers would take a reference to each other. Those circular references would make driver unloading impossible. I haven't found a good solution for that problem yet (hence the RFC state of those patches), and I would appreciate your input here. This might also be a hint that the framework design is wrong to start with. I guess I can't get everything right on the first try ;-) Getting hold of the panel is the most complex part. Once done, display drivers can call abstract operations provided by panel drivers to control the panel operation. These patches implement three of those operations (enable, start transfer and get modes). More operations will be needed, and those three operations will likely get modified during review. Most of the panels on devices I own are dumb panels with no control bus, and are thus not the best candidates to design a framework that needs to take complex panels' needs into account. In addition to the generic panel core, I've implemented MIPI DBI (Display Bus Interface, a parallel bus for panels that supports read/write transfers of commands and data) bus support, as well as three panel drivers (dummy panels with no control bus, and Renesas R61505- and R61517-based panels, both using DBI as their control bus). Only the dummy panel driver has been tested as I lack hardware for the two other drivers. I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If you can find a clever way to solve the cyclic references issue described above I'll buy you a beer at the next conference we will both attend. If you think the proposed solution is too complex, or too simple, I'm all ears. I personally already feel that we might need something even more generic to support other kinds of external devices connected to display controllers, such as external DSI to HDMI converters for instance. Some kind of video entity exposing abstract operations like the panels do would make sense, in which case panels would "inherit" from that video entity. Speaking of conferences, I will attend the KS/LPC in San Diego in a bit more than a week, and would be happy to discuss this topic face to face there. Laurent Pinchart (5): video: Add generic display panel core video: panel: Add dummy panel support video: panel: Add MIPI DBI bus support video: panel: Add R61505 panel support video: panel: Add R61517 panel support drivers/video/Kconfig | 1 + drivers/video/Makefile | 1 + drivers/video/panel/Kconfig | 37 +++ drivers/video/panel/Makefile | 5 + drivers/video/panel/panel-dbi.c | 217 +++++++++++++++ drivers/video/panel/panel-dummy.c | 103 +++++++ drivers/video/panel/panel-r61505.c | 520 ++++++++++++++++++++++++++++++++++++ drivers/video/panel/panel-r61517.c | 408 ++++++++++++++++++++++++++++ drivers/video/panel/panel.c | 269 +++++++++++++++++++ include/video/panel-dbi.h | 92 +++++++ include/video/panel-dummy.h | 25 ++ include/video/panel-r61505.h | 27 ++ include/video/panel-r61517.h | 28 ++ include/video/panel.h | 111 ++++++++ 14 files changed, 1844 insertions(+), 0 deletions(-) create mode 100644 drivers/video/panel/Kconfig create mode 100644 drivers/video/panel/Makefile create mode 100644 drivers/video/panel/panel-dbi.c create mode 100644 drivers/video/panel/panel-dummy.c create mode 100644 drivers/video/panel/panel-r61505.c create mode 100644 drivers/video/panel/panel-r61517.c create mode 100644 drivers/video/panel/panel.c create mode 100644 include/video/panel-dbi.h create mode 100644 include/video/panel-dummy.h create mode 100644 include/video/panel-r61505.h create mode 100644 include/video/panel-r61517.h create mode 100644 include/video/panel.h -- Regards, Laurent Pinchart

8 35

[Bug 40211] New: texture probleme in wolfenstein enemy territory rv770
by bugzilla-daemon＠freedesktop.org 24 Oct '12

24 Oct '12

https://bugs.freedesktop.org/show_bug.cgi?id=40211 Summary: texture probleme in wolfenstein enemy territory rv770 Product: Mesa Version: 7.10 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: pitamila(a)free.fr Hi, I can't play wolfenstein enemy territory, the texture in the upper part of the screen are blinking. I have an rv770 ati card. I run: debian sid, 3.0.0-1 linux kernel, xorg 1.10.3 OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 2.1 Mesa 7.11-devel regards, Pierre -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 16

← Newer
1
...
37
38
39
40
41
42
43
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2012