[PATCH] drm/radeon/kms: r6xx/r7xx flush shader cache at fence emision V2

2010-08-27 Thread jgli...@redhat.com 
From: Jerome Glisse 

GPU is prone to lockup if we deallocate shader bo right after
submitting command using the shader. Force shader cache flush
after each batch submission seems to fix the issue. It could
fix some of the lockup people were experiencing.

V2 move shader flush after pipeline flush it seems to be more
reliable that way (ie if userspace didn't submit a flush
pipeline at end of its command buffer we might still lockup
while moving shader flush after fence flush pipeline seems
to prevent this).

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r600.c  |6 ++
 drivers/gpu/drm/radeon/r600_blit_kms.c |2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d0ebae9..eab8de0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2337,6 +2337,12 @@ void r600_fence_ring_emit(struct radeon_device *rdev,

radeon_ring_write(rdev, PACKET3(PACKET3_EVENT_WRITE, 0));
radeon_ring_write(rdev, CACHE_FLUSH_AND_INV_EVENT);
+   /* flush shader */
+   radeon_ring_write(rdev, PACKET3(PACKET3_SURFACE_SYNC, 3));
+   radeon_ring_write(rdev, PACKET3_SH_ACTION_ENA);
+   radeon_ring_write(rdev, 0x);
+   radeon_ring_write(rdev, 0x);
+   radeon_ring_write(rdev, 10);
/* wait for 3D idle clean */
radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONFIG_REG, 1));
radeon_ring_write(rdev, (WAIT_UNTIL - PACKET3_SET_CONFIG_REG_OFFSET) >> 
2);
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index d13622a..0efba07 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -581,7 +581,7 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, int 
size_bytes)
ring_size += 40; /* shaders + def state */
ring_size += 10; /* fence emit for VB IB */
ring_size += 5; /* done copy */
-   ring_size += 10; /* fence emit for done copy */
+   ring_size += 15; /* fence emit for done copy */
r = radeon_ring_lock(rdev, ring_size);
if (r)
return r;
-- 
1.7.2.2

[PATCH] drm/radeon/kms: r6xx/r7xx flush shader cache at fence emision

2010-08-27 Thread jgli...@redhat.com 
From: Jerome Glisse 

GPU is prone to lockup if we deallocate shader bo right after
submitting command using the shader. Force shader cache flush
after each batch submission seems to fix the issue. It could
fix some of the lockup people were experiencing.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r600.c  |7 +++
 drivers/gpu/drm/radeon/r600_blit_kms.c |2 +-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d0ebae9..4076443 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2335,6 +2335,13 @@ void r600_fence_ring_emit(struct radeon_device *rdev,
 {
/* Also consider EVENT_WRITE_EOP.  it handles the interrupts + 
timestamps + events */

+   /* flush shader */
+   radeon_ring_write(rdev, PACKET3(PACKET3_SURFACE_SYNC, 3));
+   radeon_ring_write(rdev, PACKET3_SH_ACTION_ENA);
+   radeon_ring_write(rdev, 0x);
+   radeon_ring_write(rdev, 0x);
+   radeon_ring_write(rdev, 10);
+
radeon_ring_write(rdev, PACKET3(PACKET3_EVENT_WRITE, 0));
radeon_ring_write(rdev, CACHE_FLUSH_AND_INV_EVENT);
/* wait for 3D idle clean */
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index d13622a..0efba07 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -581,7 +581,7 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, int 
size_bytes)
ring_size += 40; /* shaders + def state */
ring_size += 10; /* fence emit for VB IB */
ring_size += 5; /* done copy */
-   ring_size += 10; /* fence emit for done copy */
+   ring_size += 15; /* fence emit for done copy */
r = radeon_ring_lock(rdev, ring_size);
if (r)
return r;
-- 
1.7.2.1

[PATCH] drm/radeon/kms: r6xx/r7xx flush shader cache at fence emision

2010-08-27 Thread jglisse 
From: Jerome Glisse jgli...@redhat.com

GPU is prone to lockup if we deallocate shader bo right after
submitting command using the shader. Force shader cache flush
after each batch submission seems to fix the issue. It could
fix some of the lockup people were experiencing.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r600.c  |7 +++
 drivers/gpu/drm/radeon/r600_blit_kms.c |2 +-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d0ebae9..4076443 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2335,6 +2335,13 @@ void r600_fence_ring_emit(struct radeon_device *rdev,
 {
/* Also consider EVENT_WRITE_EOP.  it handles the interrupts + 
timestamps + events */
 
+   /* flush shader */
+   radeon_ring_write(rdev, PACKET3(PACKET3_SURFACE_SYNC, 3));
+   radeon_ring_write(rdev, PACKET3_SH_ACTION_ENA);
+   radeon_ring_write(rdev, 0x);
+   radeon_ring_write(rdev, 0x);
+   radeon_ring_write(rdev, 10);
+
radeon_ring_write(rdev, PACKET3(PACKET3_EVENT_WRITE, 0));
radeon_ring_write(rdev, CACHE_FLUSH_AND_INV_EVENT);
/* wait for 3D idle clean */
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index d13622a..0efba07 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -581,7 +581,7 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, int 
size_bytes)
ring_size += 40; /* shaders + def state */
ring_size += 10; /* fence emit for VB IB */
ring_size += 5; /* done copy */
-   ring_size += 10; /* fence emit for done copy */
+   ring_size += 15; /* fence emit for done copy */
r = radeon_ring_lock(rdev, ring_size);
if (r)
return r;
-- 
1.7.2.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: r6xx/r7xx flush shader cache at fence emision V2

2010-08-27 Thread jglisse 
From: Jerome Glisse jgli...@redhat.com

GPU is prone to lockup if we deallocate shader bo right after
submitting command using the shader. Force shader cache flush
after each batch submission seems to fix the issue. It could
fix some of the lockup people were experiencing.

V2 move shader flush after pipeline flush it seems to be more
reliable that way (ie if userspace didn't submit a flush
pipeline at end of its command buffer we might still lockup
while moving shader flush after fence flush pipeline seems
to prevent this).

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r600.c  |6 ++
 drivers/gpu/drm/radeon/r600_blit_kms.c |2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d0ebae9..eab8de0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2337,6 +2337,12 @@ void r600_fence_ring_emit(struct radeon_device *rdev,
 
radeon_ring_write(rdev, PACKET3(PACKET3_EVENT_WRITE, 0));
radeon_ring_write(rdev, CACHE_FLUSH_AND_INV_EVENT);
+   /* flush shader */
+   radeon_ring_write(rdev, PACKET3(PACKET3_SURFACE_SYNC, 3));
+   radeon_ring_write(rdev, PACKET3_SH_ACTION_ENA);
+   radeon_ring_write(rdev, 0x);
+   radeon_ring_write(rdev, 0x);
+   radeon_ring_write(rdev, 10);
/* wait for 3D idle clean */
radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONFIG_REG, 1));
radeon_ring_write(rdev, (WAIT_UNTIL - PACKET3_SET_CONFIG_REG_OFFSET)  
2);
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index d13622a..0efba07 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -581,7 +581,7 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, int 
size_bytes)
ring_size += 40; /* shaders + def state */
ring_size += 10; /* fence emit for VB IB */
ring_size += 5; /* done copy */
-   ring_size += 10; /* fence emit for done copy */
+   ring_size += 15; /* fence emit for done copy */
r = radeon_ring_lock(rdev, ring_size);
if (r)
return r;
-- 
1.7.2.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel