[Bug 51787] performance regression with llvm shader compiler in ut2004

https://bugs.freedesktop.org/show_bug.cgi?id=51787 --- Comment #3 from Andy Furniss 2012-08-02 22:32:43 UTC --- (In reply to comment #2) > It might not help in fixing this, but I found that the framerate is much more > consistent if I load all cpu cores with something while playing ut2004. >

[Bug 51787] performance regression with llvm shader compiler in ut2004

https://bugs.freedesktop.org/show_bug.cgi?id=51787 --- Comment #2 from almos 2012-08-02 22:04:09 UTC --- It might not help in fixing this, but I found that the framerate is much more consistent if I load all cpu cores with something while playing ut2004. Normally, the framerate counter is green,

[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events

On Thu, Aug 2, 2012 at 9:40 PM, Zhang Rui wrote: > On ?, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote: >> On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote: >> > On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: >> > > AMD ACPI interface may overload the standard event >> > >

drm/nouveau: crash regression in 3.5

On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Gl?ck wrote: > I have managed to turn the crash into a WARN_ON, by adding this to the > begin of nouveau_software_vblank(): > > if (!psw) { > WARN_ON(1); > return; > } Yes, I know about it, but

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher wrote: > I admit I'm not really an ACPI expert, but thinking about this more, > I'm wondering if maybe we should just send the appropriate brightness > change, switch display, etc. event to userspace rather than handling > it directly in the radeon

[PATCHv7 03/15] v4l: vb2: add support for shared buffer (dma_buf)

Hi Laurent, Hi Dima, On 06/27/2012 10:40 PM, Laurent Pinchart wrote: > Hi Dima, > > On Tuesday 26 June 2012 13:53:34 Dima Zavin wrote: >> On Tue, Jun 26, 2012 at 2:40 AM, Hans Verkuil wrote: >>> On Tue 26 June 2012 11:11:06 Laurent Pinchart wrote: On Tuesday 26 June 2012 10:40:44 Tomasz

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

On Thu, Aug 2, 2012 at 12:33 PM, Alex Deucher wrote: > On Thu, Aug 2, 2012 at 12:31 PM, Luca Tettamanti > wrote: >> On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher >> wrote: >>> I admit I'm not really an ACPI expert, but thinking about this more, >>> I'm wondering if maybe we should just send

[RFC 0/3] solving omapdrm/omapdss layering issues

tuff we have. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120802/ca1d188c/attachment.pgp>

[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events

On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote: > On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: > > AMD ACPI interface may overload the standard event > > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such > > cases we don't want to send the keypress

[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

Hi, Lucas, sorry for so long a delay because I have a holiday for one month. I found Loongson-3 must turn on SWIOTLB if the system memory has addresses above 4G. As I know, there are two ways to get a DMA addr, the first way is use dma_alloc_coherent(), and the other one is use

[PATCH v2] of: Add videomode helper

On 07/05/2012 08:51 AM, Rob Herring wrote: > On 07/04/2012 02:56 AM, Sascha Hauer wrote: >> This patch adds a helper function for parsing videomodes from the devicetree. >> The videomode can be either converted to a struct drm_display_mode or a >> struct fb_videomode. >> diff --git

[PATCH v2] of: Add videomode helper

On 07/04/2012 01:56 AM, Sascha Hauer wrote: > This patch adds a helper function for parsing videomodes from the devicetree. > The videomode can be either converted to a struct drm_display_mode or a > struct fb_videomode. > diff --git a/Documentation/devicetree/bindings/video/displaymode >

drm/nouveau: crash regression in 3.5

I have managed to turn the crash into a WARN_ON, by adding this to the begin of nouveau_software_vblank(): if (!psw) { WARN_ON(1); return; } And I have also managed to load the module manually instead by udev. So I am happy to attach a full

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

On Thu, Aug 2, 2012 at 12:31 PM, Luca Tettamanti wrote: > On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher wrote: >> I admit I'm not really an ACPI expert, but thinking about this more, >> I'm wondering if maybe we should just send the appropriate brightness >> change, switch display, etc. event to

[PATCH] drm/radeon: fix virtual memory locking in case of reset

On Thu, Aug 2, 2012 at 12:05 PM, wrote: > From: Jerome Glisse > > Lock/unlock mutex in proper order to avoid deadlock in case > of GPU reset triggered from VM code path. > > Cc: stable at vger.kernel.org [3.5] > Signed-off-by: Jerome Glisse Reviewed-by: Alex Deucher > --- >

[PATCH] drm/radeon: fix virtual memory locking in case of reset

From: Jerome Glisse Lock/unlock mutex in proper order to avoid deadlock in case of GPU reset triggered from VM code path. Cc: stable at vger.kernel.org [3.5] Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/radeon_gart.c | 11 +-- 1 file changed, 9

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

I admit I'm not really an ACPI expert, but thinking about this more, I'm wondering if maybe we should just send the appropriate brightness change, switch display, etc. event to userspace rather than handling it directly in the radeon driver, then let userspace callback down via the bl interface,

[RFC 0/3] solving omapdrm/omapdss layering issues

re Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120802/7f7e4611/attachment-0001.pgp>

[PATCHv2 3/9] v4l: add buffer exporting via dmabuf

Le jeudi 2 ao?t 2012 09:35:58 Hans Verkuil, vous avez ?crit : > On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote: > > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at > > > runtime ? > > > > Does CREATE_BUFS always work while already streaming has already started? > > If

[PATCH] drm: ignore disconnected <-> unknown status changes

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20120802/eb35539b/attachment-0001.bin>

[RFC 0/3] solving omapdrm/omapdss layering issues

On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen wrote: > On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: >> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen >> wrote: >> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: >> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >> >> wrote: >>

[PATCHv2 3/9] v4l: add buffer exporting via dmabuf

On Thu August 2 2012 08:56:43 R?mi Denis-Courmont wrote: > Le jeudi 2 ao?t 2012 09:35:58 Hans Verkuil, vous avez ?crit : > > On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote: > > > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at > > > > runtime ? > > > > > > Does

[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events

On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: > AMD ACPI interface may overload the standard event > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the > userspace because the user did not press

[PATCHv2 3/9] v4l: add buffer exporting via dmabuf

On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote: > Le mercredi 1 ao?t 2012 14:35:03 Laurent Pinchart, vous avez ?crit : > > > But in general, the V4L element in the pipeline does not know how fast > > > the downstream element(s) will consume the buffers. Thus it has to copy > > > from the

Massive power regression going 3.4->3.5

On Wed, 2012-08-01 at 22:08 -0700, bwidawsk wrote: > On 2012-08-01 03:06, Chris Wilson wrote: > > On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley > > wrote: > >> On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: > >> > On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley > >> wrote: >

[RFC 0/3] solving omapdrm/omapdss layering issues

On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote: > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >> wrote: > >> > I guess the fact is that DRM concepts do not really match the OMAP DSS >> > hardware, and we'll have to use whatever

Massive power regression going 3.4->3.5

On 2012-08-02 00:20, James Bottomley wrote: > On Wed, 2012-08-01 at 22:08 -0700, bwidawsk wrote: >> On 2012-08-01 03:06, Chris Wilson wrote: >> > On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley >> > wrote: >> >> On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: >> >> > On Wed, 01 Aug

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #83 from Jerome Glisse 2012-08-02 03:46:43 UTC --- How do you trigger the va issue ? piglit ? I was not able to reproduce. It's kind of painful to debug in the dark. -- Configure bugmail:

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #82 from Alexandre Demers 2012-08-02 01:02:42 UTC --- (In reply to comment #80) > I tried both patches, the one from comment 76 and the one from comment 70, > neither fixed the issue with the rendering regression or the va conflict.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #81 from Anthony Waters 2012-08-02 00:47:06 UTC --- Created attachment 65051 --> https://bugs.freedesktop.org/attachment.cgi?id=65051 fixes to wait on the bo and to free the va after the kernel These are the changes I made to

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #80 from Anthony Waters 2012-08-02 00:41:23 UTC --- I tried both patches, the one from comment 76 and the one from comment 70, neither fixed the issue with the rendering regression or the va conflict. -- Configure bugmail:

[PATCHv2 3/9] v4l: add buffer exporting via dmabuf

Le mercredi 1 ao?t 2012 14:35:03 Laurent Pinchart, vous avez ?crit : > > But in general, the V4L element in the pipeline does not know how fast > > the downstream element(s) will consume the buffers. Thus it has to copy > > from the MMAP buffers into anonymous user memory pending processing. > >

Re: [PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

Hi, Lucas, sorry for so long a delay because I have a holiday for one month. I found Loongson-3 must turn on SWIOTLB if the system memory has addresses above 4G. As I know, there are two ways to get a DMA addr, the first way is use dma_alloc_coherent(), and the other one is use

Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf

On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: Le mercredi 1 août 2012 14:35:03 Laurent Pinchart, vous avez écrit : But in general, the V4L element in the pipeline does not know how fast the downstream element(s) will consume the buffers. Thus it has to copy from the MMAP

Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf

On Thu August 2 2012 08:56:43 Rémi Denis-Courmont wrote: Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit : On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work

Re: [RFC 0/3] solving omapdrm/omapdss layering issues

On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: I guess the fact is that DRM concepts do not really match the OMAP DSS hardware, and we'll have to use whatever gives us least problems. Actually, I think it

Re: Massive power regression going 3.4-3.5

On Wed, 2012-08-01 at 22:08 -0700, bwidawsk wrote: On 2012-08-01 03:06, Chris Wilson wrote: On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley james.bottom...@hansenpartnership.com wrote: On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: On Wed, 01 Aug 2012 09:45:04 +0100, James

Re: Massive power regression going 3.4-3.5

On 2012-08-02 00:20, James Bottomley wrote: On Wed, 2012-08-01 at 22:08 -0700, bwidawsk wrote: On 2012-08-01 03:06, Chris Wilson wrote: On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley james.bottom...@hansenpartnership.com wrote: On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: On

Re: [RFC 0/3] solving omapdrm/omapdss layering issues

On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: I guess the fact is that DRM concepts do not really match the OMAP DSS hardware, and

Re: [RFC 0/3] solving omapdrm/omapdss layering issues

On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: I guess the fact is that DRM

Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events

On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote: On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: AMD ACPI interface may overload the standard event ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such cases we don't want to send the keypress

Re: [RFC 0/3] solving omapdrm/omapdss layering issues

On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: On Wed, Aug 1, 2012 at 4:21 AM, Tomi

Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code

I admit I'm not really an ACPI expert, but thinking about this more, I'm wondering if maybe we should just send the appropriate brightness change, switch display, etc. event to userspace rather than handling it directly in the radeon driver, then let userspace callback down via the bl interface,

[PATCH] drm/radeon: fix virtual memory locking in case of reset

From: Jerome Glisse jgli...@redhat.com Lock/unlock mutex in proper order to avoid deadlock in case of GPU reset triggered from VM code path. Cc: sta...@vger.kernel.org [3.5] Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon_gart.c | 11 +-- 1 file

Re: [PATCH] drm/radeon: fix virtual memory locking in case of reset

On Thu, Aug 2, 2012 at 12:05 PM, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Lock/unlock mutex in proper order to avoid deadlock in case of GPU reset triggered from VM code path. Cc: sta...@vger.kernel.org [3.5] Signed-off-by: Jerome Glisse jgli...@redhat.com

Re: [PATCHv7 03/15] v4l: vb2: add support for shared buffer (dma_buf)

Hi Laurent, Hi Dima, On 06/27/2012 10:40 PM, Laurent Pinchart wrote: Hi Dima, On Tuesday 26 June 2012 13:53:34 Dima Zavin wrote: On Tue, Jun 26, 2012 at 2:40 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Tue 26 June 2012 11:11:06 Laurent Pinchart wrote: On Tuesday 26 June 2012 10:40:44

Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code

On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher alexdeuc...@gmail.com wrote: I admit I'm not really an ACPI expert, but thinking about this more, I'm wondering if maybe we should just send the appropriate brightness change, switch display, etc. event to userspace rather than handling it directly

Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code

On Thu, Aug 2, 2012 at 12:31 PM, Luca Tettamanti kronos...@gmail.com wrote: On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher alexdeuc...@gmail.com wrote: I admit I'm not really an ACPI expert, but thinking about this more, I'm wondering if maybe we should just send the appropriate brightness

Re: drm/nouveau: crash regression in 3.5

On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Glück wrote: I have managed to turn the crash into a WARN_ON, by adding this to the begin of nouveau_software_vblank(): if (!psw) { WARN_ON(1); return; } Yes, I know about it, but this

Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code

On Thu, Aug 2, 2012 at 12:33 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Aug 2, 2012 at 12:31 PM, Luca Tettamanti kronos...@gmail.com wrote: On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher alexdeuc...@gmail.com wrote: I admit I'm not really an ACPI expert, but thinking about this more,

Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf

Hi Rémi, On Thursday 02 August 2012 09:56:43 Rémi Denis-Courmont wrote: Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit : On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does

Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf

Hi Hans, On Thursday 02 August 2012 09:08:18 Hans Verkuil wrote: On Thu August 2 2012 08:56:43 Rémi Denis-Courmont wrote: Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit : On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: What about using the CREATE_BUFS ioctl to add

[Bug 51787] performance regression with llvm shader compiler in ut2004

https://bugs.freedesktop.org/show_bug.cgi?id=51787 --- Comment #2 from almos aaalmo...@gmail.com 2012-08-02 22:04:09 UTC --- It might not help in fixing this, but I found that the framerate is much more consistent if I load all cpu cores with something while playing ut2004. Normally, the

[Bug 51787] performance regression with llvm shader compiler in ut2004

https://bugs.freedesktop.org/show_bug.cgi?id=51787 --- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com 2012-08-02 22:32:43 UTC --- (In reply to comment #2) It might not help in fixing this, but I found that the framerate is much more consistent if I load all cpu cores with something

Re: Massive power regression going 3.4-3.5

On 2012-08-01 03:06, Chris Wilson wrote: On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley james.bottom...@hansenpartnership.com wrote: On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley james.bottom...@hansenpartnership.com wrote:

[PATCH] drm: ignore disconnected - unknown status changes

On an AOpen i915GMm-hfs the hotplug events generated by transitions between connector_status_unknown and connector_status_disconnected cause screen distortions. The attached patch cures the problem by disabling the generation of hotplug events in those cases. That should be safe for everybody as

Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf

Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit : On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends

Re: [PATCH v2] of: Add videomode helper

On 07/04/2012 01:56 AM, Sascha Hauer wrote: This patch adds a helper function for parsing videomodes from the devicetree. The videomode can be either converted to a struct drm_display_mode or a struct fb_videomode. diff --git a/Documentation/devicetree/bindings/video/displaymode

Re: [PATCH v2] of: Add videomode helper

On 07/05/2012 08:51 AM, Rob Herring wrote: On 07/04/2012 02:56 AM, Sascha Hauer wrote: This patch adds a helper function for parsing videomodes from the devicetree. The videomode can be either converted to a struct drm_display_mode or a struct fb_videomode. diff --git

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #84 from Anthony Waters awate...@gmail.com 2012-08-03 01:28:25 UTC --- I randomly saw it when I was playing a game of Warcraft 3, the terrain textures would blink. I'll check the piglit tests and mesa demos to see if I can reproduce

Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events

On Thu, Aug 2, 2012 at 9:40 PM, Zhang Rui rui.zh...@intel.com wrote: On 四, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote: On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote: On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: AMD ACPI interface may overload the standard event

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #85 from Anthony Waters awate...@gmail.com 2012-08-03 02:07:06 UTC --- I found a demo that has the issue, in the demos repository for mesa within the src/demo folder the program 'reflect'. After I start it up and press 's' to see

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #86 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-03 03:00:00 UTC --- (In reply to comment #85) I found a demo that has the issue, in the demos repository for mesa within the src/demo folder the program 'reflect'.