Hey,
Op 13-07-12 20:52, Rob Clark schreef:
> On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey wrote:
>> My other thought is around atomicity. Could this be extended to
>> (safely) allow for hardware devices which might want to access
>> multiple buffers simultaneously? I think it probably can with
>
A way to trigger an irq will be needed for optimus support since
cpu-waiting isn't always viable there. This could also be nice for
power saving on since cpu would no longer have to spin, and
performance might improve slightly on cpu-limited workloads.
Some way to quantify these effects would be n
Hi Dave,
On Sat, Jul 14, 2012 at 01:33:45PM +1000, Dave Airlie wrote:
> Can you try this patch on top of the previous one?
>
> I think it should fix it.
You are right, it works! Thank you very much! :-)
Thanks,
Fengguang
___
dri-devel mailing list
dr
https://bugs.freedesktop.org/show_bug.cgi?id=52054
Bug #: 52054
Summary: gallium/opencl doesnt support includes for opencl
kernels
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
Hi Dave,
New pull for -next. Highlights:
- rc6/turbo support for hsw (Eugeni)
- improve corner-case of the reset handling code - gpu reset handling
should be rock-solid now
- support for fb offset > 4096 pixels on gen4+ (yeah, you need some fairly
big screens to hit that)
- the "Flush Me Harde
Can you try this patch on top of the previous one?
I think it should fix it.
Dave.
0001-drm-set-drm_class-to-NULL-after-removing-it.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/
---
tests/modetest/modetest.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index ec3121e..00129fa 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -128,6 +128,7 @@ char * res##_str(int type)
---
xf86drm.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index e652731..c1cc170 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -1399,8 +1399,11 @@ drm_context_t *drmGetReservedContextList(int fd, int
*count)
}
res.contexts = list;
-
---
xf86drm.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..e652731 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char *id2,
int pci_domain_ok)
return 0;
}
+#
---
nouveau/nouveau.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 5aa4107..e91287f 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device
**pdev
---
libkms/nouveau.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/libkms/nouveau.c b/libkms/nouveau.c
index 0e24a15..fbca6fe 100644
--- a/libkms/nouveau.c
+++ b/libkms/nouveau.c
@@ -90,21 +90,24 @@ nouveau_bo_create(struct kms_driver *kms,
---
libkms/intel.c | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/libkms/intel.c b/libkms/intel.c
index 8b8249b..12175b0 100644
--- a/libkms/intel.c
+++ b/libkms/intel.c
@@ -89,27 +89,32 @@ intel_bo_create(struct kms_driver *kms,
Am Freitag, 13. Juli 2012, 18:47:50 schrieb Marcin Slusarz:
> On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote:
> >
> > Patches 1 to 4 were sent to mesa-dev.
>
> And you chose to ignore most of my comments.
> Fine. Don't expect further reviews from me.
>
> Marcin
Patch 1 and 2
On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote:
>
> Patches 1 to 4 were sent to mesa-dev.
And you chose to ignore most of my comments.
Fine. Don't expect further reviews from me.
Marcin
Hi Rob,
Yes, sorry we've been a bit slack progressing KDS publicly. Your
approach looks interesting and seems like it could enable both implicit
and explicit synchronization. A good compromise.
> From: Rob Clark
>
> A dma-fence can be attached to a buffer which is being filled or
> consumed by
---
tests/modetest/modetest.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index ec3121e..00129fa 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -128,6 +128,7 @@ char * res##_str(int type)
---
xf86drm.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..e3789c8 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char *id2,
int pci_domain_ok)
return 0;
}
---
nouveau/nouveau.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 5aa4107..e91287f 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device
**pdev
---
libkms/nouveau.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/libkms/nouveau.c b/libkms/nouveau.c
index 0e24a15..4cbca96 100644
--- a/libkms/nouveau.c
+++ b/libkms/nouveau.c
@@ -94,14 +94,18 @@ nouveau_bo_create(struct kms_driver *kms,
if
---
libkms/intel.c | 25 ++---
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/libkms/intel.c b/libkms/intel.c
index 8b8249b..b8ac343 100644
--- a/libkms/intel.c
+++ b/libkms/intel.c
@@ -93,14 +93,18 @@ intel_bo_create(struct kms_driver *kms,
if (!bo)
Patches 1 to 4 were sent to mesa-dev.
On Fri, Jul 13, 2012 at 4:44 PM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 13-07-12 20:52, Rob Clark schreef:
>> On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey wrote:
>>> My other thought is around atomicity. Could this be extended to
>>> (safely) allow for hardware devices which might want to access
> -Original Message-
> From: Prathyush K [mailto:prathyush.k at samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel at lists.freedesktop.org
> Cc: prathyush at chromium.org; m.szyprowski at samsung.com;
inki.dae at samsung.com;
> subash.ramaswamy at linaro.org
> Subject:
Const IBs are executed on the CE not the CP, so we can't
fence them in the normal way.
So submit them directly before the IB instead, just as
the documentation says.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r100.c|2 +-
drivers/gpu/drm/radeon/r600.c|2 +-
Otherwise we can encounter out of memory situations under extreme load.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_sa.c | 72 +---
2 files changed, 51 insertions(+), 23 deletions(-)
diff --git
Otherwise the sa managers out of memory
handling doesn't work.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 76c5
> -Original Message-
> From: Prathyush K [mailto:prathyush.k at samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel at lists.freedesktop.org
> Cc: prathyush at chromium.org; m.szyprowski at samsung.com;
inki.dae at samsung.com;
> subash.ramaswamy at linaro.org
> Subject:
On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst
wrote:
> A way to trigger an irq will be needed for optimus support since
> cpu-waiting isn't always viable there. This could also be nice for
> power saving on since cpu would no longer have to spin, and
> performance might improve slightly on c
> -Original Message-
> From: Prathyush K [mailto:prathyush.k at samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel at lists.freedesktop.org
> Cc: prathyush at chromium.org; m.szyprowski at samsung.com;
inki.dae at samsung.com;
> subash.ramaswamy at linaro.org
> Subject:
> -Original Message-
> From: Prathyush K [mailto:prathyush.k at samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel at lists.freedesktop.org
> Cc: prathyush at chromium.org; m.szyprowski at samsung.com;
inki.dae at samsung.com;
> subash.ramaswamy at linaro.org
> Subject:
On 13.07.2012 14:27, Alex Deucher wrote:
> On Fri, Jul 13, 2012 at 5:09 AM, Christian K?nig
> wrote:
>> On 12.07.2012 18:36, Alex Deucher wrote:
>>> On Thu, Jul 12, 2012 at 12:12 PM, Christian K?nig
>>> wrote:
Before emitting any indirect buffer, emit the offset of the next
valid ring c
> -Original Message-
> From: Prathyush K [mailto:prathyush.k at samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel at lists.freedesktop.org
> Cc: prathyush at chromium.org; m.szyprowski at samsung.com;
inki.dae at samsung.com;
> subash.ramaswamy at linaro.org
> Subject:
On Fri, Jul 13, 2012 at 4:44 PM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 13-07-12 20:52, Rob Clark schreef:
>> On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey wrote:
>>> My other thought is around atomicity. Could this be extended to
>>> (safely) allow for hardware devices which might want to access
A way to trigger an irq will be needed for optimus support since
cpu-waiting isn't always viable there. This could also be nice for
power saving on since cpu would no longer have to spin, and
performance might improve slightly on cpu-limited workloads.
Some way to quantify these effects would be n
On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey wrote:
> My other thought is around atomicity. Could this be extended to
> (safely) allow for hardware devices which might want to access
> multiple buffers simultaneously? I think it probably can with
> some tweaks to the interface? An atomic function
On 07/13/2012 12:09 PM, Inki Dae wrote:
>
>> -Original Message-
>> From: Prathyush K [mailto:prathyush.k at samsung.com]
>> Sent: Wednesday, July 11, 2012 6:40 PM
>> To: dri-devel at lists.freedesktop.org
>> Cc: prathyush at chromium.org; m.szyprowski at samsung.com;
> inki.dae at samsung.c
Hi Dave,
New pull for -next. Highlights:
- rc6/turbo support for hsw (Eugeni)
- improve corner-case of the reset handling code - gpu reset handling
should be rock-solid now
- support for fb offset > 4096 pixels on gen4+ (yeah, you need some fairly
big screens to hit that)
- the "Flush Me Harde
On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey wrote:
> My other thought is around atomicity. Could this be extended to
> (safely) allow for hardware devices which might want to access
> multiple buffers simultaneously? I think it probably can with
> some tweaks to the interface? An atomic function
---
tests/modetest/modetest.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index ec3121e..00129fa 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -128,6 +128,7 @@ char * res##_str(int type)
---
xf86drm.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index e652731..c1cc170 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -1399,8 +1399,11 @@ drm_context_t *drmGetReservedContextList(int fd, int
*count)
}
res.contexts = list;
-
---
xf86drm.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..e652731 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char *id2,
int pci_domain_ok)
return 0;
}
+
---
nouveau/nouveau.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 5aa4107..e91287f 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device
**pdev
---
libkms/nouveau.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/libkms/nouveau.c b/libkms/nouveau.c
index 0e24a15..fbca6fe 100644
--- a/libkms/nouveau.c
+++ b/libkms/nouveau.c
@@ -90,21 +90,24 @@ nouveau_bo_create(struct kms_driver *kms,
---
libkms/intel.c | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/libkms/intel.c b/libkms/intel.c
index 8b8249b..12175b0 100644
--- a/libkms/intel.c
+++ b/libkms/intel.c
@@ -89,27 +89,32 @@ intel_bo_create(struct kms_driver *kms,
Am Freitag, 13. Juli 2012, 18:47:50 schrieb Marcin Slusarz:
> On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote:
> >
> > Patches 1 to 4 were sent to mesa-dev.
>
> And you chose to ignore most of my comments.
> Fine. Don't expect further reviews from me.
>
> Marcin
Patch 1 and 2
On 12.07.2012 18:36, Alex Deucher wrote:
> On Thu, Jul 12, 2012 at 12:12 PM, Christian K?nig
> wrote:
>> Before emitting any indirect buffer, emit the offset of the next
>> valid ring content if any. This allow code that want to resume
>> ring to resume ring right after ib that caused GPU lockup.
On Fri, Jul 13, 2012 at 10:08 AM, Christian K?nig
wrote:
> Const IBs are executed on the CE not the CP, so we can't
> fence them in the normal way.
>
> So submit them directly before the IB instead, just as
> the documentation says.
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/rade
Hi Rob,
Yes, sorry we've been a bit slack progressing KDS publicly. Your
approach looks interesting and seems like it could enable both implicit
and explicit synchronization. A good compromise.
> From: Rob Clark
>
> A dma-fence can be attached to a buffer which is being filled or
> consumed by
From: Rob Clark
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU
On Fri, Jul 13, 2012 at 04:08:15PM +0200, Christian K?nig wrote:
> Const IBs are executed on the CE not the CP, so we can't
> fence them in the normal way.
>
> So submit them directly before the IB instead, just as
> the documentation says.
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu
On Fri, Jul 13, 2012 at 04:08:14PM +0200, Christian K?nig wrote:
> Otherwise we can encounter out of memory situations under extreme load.
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon.h|2 +-
> drivers/gpu/drm/radeon/radeon_sa.c | 72
> +
On Fri, Jul 13, 2012 at 9:46 AM, Christian K?nig
wrote:
> On 13.07.2012 14:27, Alex Deucher wrote:
>>
>> On Fri, Jul 13, 2012 at 5:09 AM, Christian K?nig
>> wrote:
>>>
>>> On 12.07.2012 18:36, Alex Deucher wrote:
On Thu, Jul 12, 2012 at 12:12 PM, Christian K?nig
wrote:
>
>
On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote:
>
> Patches 1 to 4 were sent to mesa-dev.
And you chose to ignore most of my comments.
Fine. Don't expect further reviews from me.
Marcin
___
dri-devel mailing list
dri-devel@lists.free
On 13.07.2012 00:23, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Retry label was at wrong place in function leading to memory
> leak.
>
> Cc:
> Signed-off-by: Jerome Glisse
Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon_object.c |3 ++-
> 1 file changed, 2
---
tests/modetest/modetest.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index ec3121e..00129fa 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -128,6 +128,7 @@ char * res##_str(int type)
---
xf86drm.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..e3789c8 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char *id2,
int pci_domain_ok)
return 0;
}
---
nouveau/nouveau.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 5aa4107..e91287f 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device
**pdev
---
libkms/intel.c | 25 ++---
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/libkms/intel.c b/libkms/intel.c
index 8b8249b..b8ac343 100644
--- a/libkms/intel.c
+++ b/libkms/intel.c
@@ -93,14 +93,18 @@ intel_bo_create(struct kms_driver *kms,
if (!bo)
---
libkms/nouveau.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/libkms/nouveau.c b/libkms/nouveau.c
index 0e24a15..4cbca96 100644
--- a/libkms/nouveau.c
+++ b/libkms/nouveau.c
@@ -94,14 +94,18 @@ nouveau_bo_create(struct kms_driver *kms,
if
Patches 1 to 4 were sent to mesa-dev.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Rob Clark
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU
On Fri, Jul 13, 2012 at 5:09 AM, Christian K?nig
wrote:
> On 12.07.2012 18:36, Alex Deucher wrote:
>>
>> On Thu, Jul 12, 2012 at 12:12 PM, Christian K?nig
>> wrote:
>>>
>>> Before emitting any indirect buffer, emit the offset of the next
>>> valid ring content if any. This allow code that want to
https://bugs.freedesktop.org/show_bug.cgi?id=52054
Bug #: 52054
Summary: gallium/opencl doesnt support includes for opencl
kernels
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
On Fri, Jul 13, 2012 at 10:08 AM, Christian König
wrote:
> Const IBs are executed on the CE not the CP, so we can't
> fence them in the normal way.
>
> So submit them directly before the IB instead, just as
> the documentation says.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/rade
On Don, 2012-07-12 at 18:23 -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Retry label was at wrong place in function leading to memory
> leak.
>
> Cc:
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_object.c |3 ++-
> 1 file changed, 2 insertions(+),
On Fri, Jul 13, 2012 at 04:08:15PM +0200, Christian König wrote:
> Const IBs are executed on the CE not the CP, so we can't
> fence them in the normal way.
>
> So submit them directly before the IB instead, just as
> the documentation says.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu
On Fri, Jul 13, 2012 at 04:08:14PM +0200, Christian König wrote:
> Otherwise we can encounter out of memory situations under extreme load.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h|2 +-
> drivers/gpu/drm/radeon/radeon_sa.c | 72
> +
Const IBs are executed on the CE not the CP, so we can't
fence them in the normal way.
So submit them directly before the IB instead, just as
the documentation says.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/r100.c|2 +-
drivers/gpu/drm/radeon/r600.c|2 +-
Otherwise we can encounter out of memory situations under extreme load.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_sa.c | 72 +---
2 files changed, 51 insertions(+), 23 deletions(-)
diff --git
Otherwise the sa managers out of memory
handling doesn't work.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 76c5
On Fri, Jul 13, 2012 at 9:46 AM, Christian König
wrote:
> On 13.07.2012 14:27, Alex Deucher wrote:
>>
>> On Fri, Jul 13, 2012 at 5:09 AM, Christian König
>> wrote:
>>>
>>> On 12.07.2012 18:36, Alex Deucher wrote:
On Thu, Jul 12, 2012 at 12:12 PM, Christian König
wrote:
>
>
On 13.07.2012 14:27, Alex Deucher wrote:
On Fri, Jul 13, 2012 at 5:09 AM, Christian König
wrote:
On 12.07.2012 18:36, Alex Deucher wrote:
On Thu, Jul 12, 2012 at 12:12 PM, Christian König
wrote:
Before emitting any indirect buffer, emit the offset of the next
valid ring content if any. This
On Fri, Jul 13, 2012 at 5:09 AM, Christian König
wrote:
> On 12.07.2012 18:36, Alex Deucher wrote:
>>
>> On Thu, Jul 12, 2012 at 12:12 PM, Christian König
>> wrote:
>>>
>>> Before emitting any indirect buffer, emit the offset of the next
>>> valid ring content if any. This allow code that want to
On 07/13/2012 12:09 PM, Inki Dae wrote:
-Original Message-
From: Prathyush K [mailto:prathyus...@samsung.com]
Sent: Wednesday, July 11, 2012 6:40 PM
To: dri-devel@lists.freedesktop.org
Cc: prathy...@chromium.org; m.szyprow...@samsung.com;
inki@samsung.com;
subash.ramasw...@linaro.
On 12.07.2012 18:36, Alex Deucher wrote:
On Thu, Jul 12, 2012 at 12:12 PM, Christian König
wrote:
Before emitting any indirect buffer, emit the offset of the next
valid ring content if any. This allow code that want to resume
ring to resume ring right after ib that caused GPU lockup.
v2: use s
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/drm.tmpl | 2835 +++-
1 files changed, 2226 insertions(+), 609 deletions(-)
Hi everybody,
Here's the DRM kernel framework documentation previously posted to the
dri-devel mailing list. The documentatio
On 13.07.2012 00:23, j.gli...@gmail.com wrote:
From: Jerome Glisse
Retry label was at wrong place in function leading to memory
leak.
Cc:
Signed-off-by: Jerome Glisse
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c |3 ++-
1 file changed, 2 insertions(+), 1
> -Original Message-
> From: Prathyush K [mailto:prathyus...@samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel@lists.freedesktop.org
> Cc: prathy...@chromium.org; m.szyprow...@samsung.com;
inki@samsung.com;
> subash.ramasw...@linaro.org
> Subject: [PATCH 7/7] drm/e
> -Original Message-
> From: Prathyush K [mailto:prathyus...@samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel@lists.freedesktop.org
> Cc: prathy...@chromium.org; m.szyprow...@samsung.com;
inki@samsung.com;
> subash.ramasw...@linaro.org
> Subject: [PATCH 6/7] drm/e
> -Original Message-
> From: Prathyush K [mailto:prathyus...@samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel@lists.freedesktop.org
> Cc: prathy...@chromium.org; m.szyprow...@samsung.com;
inki@samsung.com;
> subash.ramasw...@linaro.org
> Subject: [PATCH 5/7] drm/e
> -Original Message-
> From: Prathyush K [mailto:prathyus...@samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel@lists.freedesktop.org
> Cc: prathy...@chromium.org; m.szyprow...@samsung.com;
inki@samsung.com;
> subash.ramasw...@linaro.org
> Subject: [PATCH 3/7] drm/e
> -Original Message-
> From: Prathyush K [mailto:prathyus...@samsung.com]
> Sent: Wednesday, July 11, 2012 6:40 PM
> To: dri-devel@lists.freedesktop.org
> Cc: prathy...@chromium.org; m.szyprow...@samsung.com;
inki@samsung.com;
> subash.ramasw...@linaro.org
> Subject: [PATCH 0/7] [RFC]
82 matches
Mail list logo