Re: [Mesa3d-dev] [PATCH] configure.ac: Bump LIBDRM_RADEON_REQUIRED to 2.4.19
Fixed in master without requiring new libdrm. -Marek On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek sedat.di...@googlemail.comwrote: Fixes here latest issues with mesa master GIT [1]. -- Sedat [1] http://marc.info/?l=mesa3d-devm=126934502904478w=2 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list mesa3d-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [PATCH] configure.ac: Bump LIBDRM_RADEON_REQUIRED to 2.4.19
On Tue, Mar 23, 2010 at 1:57 PM, Sedat Dilek sedat.di...@googlemail.comwrote: Thanks for the turbo fix, but you workarounded the real bug. Frankly, the Mesa build system isn't my area and I don't want to have anything to do with it. The square microtiling is now disabled on both older kernels which don't support it and older libdrm's which don't have the flag defined. No need to have bleeding-edge stuff of everything is the way to go as long as it doesn't get messy. -Marek With my patch I get here in build.log: ... checking for LIBDRM... yes ... checking for LIBDRM_RADEON... no ... With setting LIBDRM_RADEON_REQUIRED=2.4.19 I expected that the build should immediately stop while libdrm package here has version 2.4.18. BUT, that is not the case! Intel_drm has in configure.ac: ... case $DRI_DIRS in *i915*|*i965*) PKG_CHECK_MODULES([INTEL], [libdrm_intel = 2.4.19]) ;; esac ... radeon_libdrm on the contrary: ... case $DRI_DIRS in *radeon*|*r200*|*r300*|*r600*) PKG_CHECK_MODULES([LIBDRM_RADEON], [libdrm_radeon libdrm = $LIBDRM_RADEON_REQUIRED], HAVE_LIBDRM_RADEON=yes, HAVE_LIBDRM_RADEON=no) if test $HAVE_LIBDRM_RADEON = yes; then RADEON_CFLAGS=-DHAVE_LIBDRM_RADEON=1 $LIBDRM_RADEON_CFLAGS RADEON_LDFLAGS=$LIBDRM_RADEON_LIBS fi ;; esac ... IMO checking for LIBDRM_RADEON_REQUIRED has no real effect, but I am not an autotools expert. I am not sure if the LIBDRM_RADEON_REQUIRED part could/should be handled like in libdrm_intel (...be removed and simplified). Feedback welcome! -- Sedat On Tue, Mar 23, 2010 at 1:41 PM, Marek Olšák mar...@gmail.com wrote: Fixed in master without requiring new libdrm. -Marek On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek sedat.di...@googlemail.com wrote: Fixes here latest issues with mesa master GIT [1]. -- Sedat [1] http://marc.info/?l=mesa3d-devm=126934502904478w=2 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list mesa3d-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT
On Fri, Mar 19, 2010 at 11:36 AM, Sedat Dilek sedat.di...@googlemail.comwrote: Hi, the last days I was testing Alex Deucher's power-management-2 patches for radeon OSS driver. While testing I saw that especially r300g dri/statetracker with OpenArena have problems with mesa 7.8/master GIT branch. Mesa r300 classic (KMS/DRI2) is working fine here on RV515. 7.8 GIT: Scenes have a red-ish background. There should be a fix in master. But I can't remember when and which patch fixed it, but Dave Airlied noticed the same color corruptions. Apply this one from master: 821c830f11fc1c3529a186ace1d1ba3ddeab4957http://cgit.freedesktop.org/mesa/mesa/commit/?id=821c830f11fc1c3529a186ace1d1ba3ddeab4957 If it helps, someone could cherry-pick the commit to the 7.8 branch. master GIT (merged gallium-st-api-dri into it): Some objects in the scene are not displayed with correct colors - objects look/have like turquoise and black triangles. What levels have this issue? How can I reproduce it? There is a breakage with Dave's screen/winsys rework ( 68e58a96e80865878e6881dc4d34fcc3ec24eb19http://cgit.freedesktop.org/mesa/mesa/commit/?id=68e58a96e80865878e6881dc4d34fcc3ec24eb19), especially in these piglit tests: cubemap, gen-teximage, levelclamp, lodclamp, texredefine. Could you please check if the incorrect rendering in openarena has anything to do with the rework? -Marek commit 8e1768cfd32a4fa47dd5d4e8f5434fafc3b3120 gallium/docs: Fix a couple ReST errors. I played a bit with glxinfo (output see file-attachment): $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa glxinfo glxinfo.txt The log of OA got big (dunno if you are interested in): $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa openarena 2openarena.log Any hints for digging deeper into this? Kind Regards, - Sedat - -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list mesa3d-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.
The attached patches change softpipe and llvmpipe so that they never provoke
the first vertex for quads. Please review. I think that these and the
Corbin's one could be pushed by now, couldn't they?
-Marek
On Thu, Feb 11, 2010 at 4:03 PM, Brian Paul bri...@vmware.com wrote:
Corbin Simpson wrote:
From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001
From: Corbin Simpson mostawesomed...@gmail.com
Date: Wed, 10 Feb 2010 10:39:18 -0800
Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking
vertex.
Fixes glean/clipFlat. Softpipe might be broken; I haven't figured out
how to test it in this new API world. :T
---
src/mesa/state_tracker/st_extensions.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index d5f5854..e2d871b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -137,6 +137,9 @@ void st_init_limits(struct st_context *st)
/* XXX separate query for early function return? */
st-ctx-Shader.EmitContReturn =
screen-get_param(screen, PIPE_CAP_TGSI_CONT_SUPPORTED);
+
+ /* Quads always follow GL provoking rules. */
+ c-QuadsFollowProvokingVertexConvention = GL_FALSE;
}
This causes the glean clipFlat test to fail with softpipe. The
gallium softpipe driver _does_ implement the quad follows provoking
vertex convention.
I don't have time right now to update the softpipe driver so this
patch will have to wait a while. Maybe someone else can look at it
sooner.
-Brian
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Mesa3d-dev mailing list
mesa3d-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
From 861dd9a4e5d2fc3e0892d76d8f0ac929e186a88a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sun, 7 Mar 2010 04:54:43 +0100
Subject: [PATCH 1/2] llvmpipe: do not follow the provoking vertex convention for quads
---
src/gallium/drivers/llvmpipe/lp_setup_vbuf.c | 129 +++--
1 files changed, 36 insertions(+), 93 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
index 24291da..671e744 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
@@ -231,57 +231,29 @@ lp_setup_draw(struct vbuf_render *vbr, const ushort *indices, uint nr)
break;
case PIPE_PRIM_QUADS:
- if (setup-flatshade_first) {
- for (i = 3; i nr; i += 4) {
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-3], stride) );
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-0], stride),
- get_vert(vertex_buffer, indices[i-3], stride) );
- }
- }
- else {
- for (i = 3; i nr; i += 4) {
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-3], stride),
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-0], stride) );
+ for (i = 3; i nr; i += 4) {
+ setup-triangle( setup,
+ get_vert(vertex_buffer, indices[i-3], stride),
+ get_vert(vertex_buffer, indices[i-2], stride),
+ get_vert(vertex_buffer, indices[i-0], stride) );
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-0], stride) );
- }
+ setup-triangle( setup,
+ get_vert(vertex_buffer, indices[i-2], stride),
+ get_vert(vertex_buffer, indices[i-1], stride),
+ get_vert(vertex_buffer, indices[i-0], stride) );
}
break;
case PIPE_PRIM_QUAD_STRIP:
- if (setup-flatshade_first) {
- for (i = 3; i nr; i += 2) {
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-0], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
-
[PATCHES] r3xx-r5xx square microtiling support
Hi,
the first patch adds square microtiling support to kernel (against
drm-linus). The second one adds the new BO tiling flag to libdrm.
This is supposed to improve texture cache efficiency for 16bit and 64bit
texture formats. It's tested with r300g and already fully working in my
private repo.
Please review/push.
Best regards
Marek Olšák
From efb253ccf8a23d38bd1c81c1eb9e6bba1a2e14a0 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sun, 14 Feb 2010 07:10:10 +0100
Subject: [PATCH] drm/radeon/kms: add support for square microtiles on r3xx-r5xx
---
drivers/gpu/drm/radeon/r300.c |8 +++-
drivers/gpu/drm/radeon/r300_reg.h |2 ++
include/drm/radeon_drm.h |1 +
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 43b55a0..c4308e9 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -707,6 +707,8 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
tile_flags |= R300_TXO_MACRO_TILE;
if (reloc-lobj.tiling_flags RADEON_TILING_MICRO)
tile_flags |= R300_TXO_MICRO_TILE;
+ else if (reloc-lobj.tiling_flags RADEON_TILING_MICRO_SQUARE)
+ tile_flags |= R300_TXO_MICRO_TILE_SQUARE;
tmp = idx_value + ((u32)reloc-lobj.gpu_offset);
tmp |= tile_flags;
@@ -757,6 +759,8 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
tile_flags |= R300_COLOR_TILE_ENABLE;
if (reloc-lobj.tiling_flags RADEON_TILING_MICRO)
tile_flags |= R300_COLOR_MICROTILE_ENABLE;
+ else if (reloc-lobj.tiling_flags RADEON_TILING_MICRO_SQUARE)
+ tile_flags |= R300_COLOR_MICROTILE_SQUARE_ENABLE;
tmp = idx_value ~(0x7 16);
tmp |= tile_flags;
@@ -828,7 +832,9 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
if (reloc-lobj.tiling_flags RADEON_TILING_MACRO)
tile_flags |= R300_DEPTHMACROTILE_ENABLE;
if (reloc-lobj.tiling_flags RADEON_TILING_MICRO)
- tile_flags |= R300_DEPTHMICROTILE_TILED;;
+ tile_flags |= R300_DEPTHMICROTILE_TILED;
+ else if (reloc-lobj.tiling_flags RADEON_TILING_MICRO_SQUARE)
+ tile_flags |= R300_DEPTHMICROTILE_TILED_SQUARE;
tmp = idx_value ~(0x7 16);
tmp |= tile_flags;
diff --git a/drivers/gpu/drm/radeon/r300_reg.h b/drivers/gpu/drm/radeon/r300_reg.h
index 1735a2b..1a0d536 100644
--- a/drivers/gpu/drm/radeon/r300_reg.h
+++ b/drivers/gpu/drm/radeon/r300_reg.h
@@ -952,6 +952,7 @@
# define R300_TXO_ENDIAN_HALFDW_SWAP (3 0)
# define R300_TXO_MACRO_TILE (1 2)
# define R300_TXO_MICRO_TILE (1 3)
+# define R300_TXO_MICRO_TILE_SQUARE(2 3)
# define R300_TXO_OFFSET_MASK 0xffe0
# define R300_TXO_OFFSET_SHIFT 5
/* END: Guess from R200 */
@@ -1360,6 +1361,7 @@
# define R300_COLORPITCH_MASK 0x1FF8 /* GUESS */
# define R300_COLOR_TILE_ENABLE(1 16) /* GUESS */
# define R300_COLOR_MICROTILE_ENABLE (1 17) /* GUESS */
+# define R300_COLOR_MICROTILE_SQUARE_ENABLE (2 17)
# define R300_COLOR_ENDIAN_NO_SWAP (0 18) /* GUESS */
# define R300_COLOR_ENDIAN_WORD_SWAP (1 18) /* GUESS */
# define R300_COLOR_ENDIAN_DWORD_SWAP (2 18) /* GUESS */
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 39537f3..81e614b 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -808,6 +808,7 @@ struct drm_radeon_gem_create {
#define RADEON_TILING_SWAP_32BIT 0x8
#define RADEON_TILING_SURFACE 0x10 /* this object requires a surface
* when mapped - i.e. front buffer */
+#define RADEON_TILING_MICRO_SQUARE 0x20
struct drm_radeon_gem_set_tiling {
uint32_t handle;
--
1.6.3.3
From 5c9261300e95e1ff12e659443b63ade998f99da7 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sun, 14 Feb 2010 17:57:19 +0100
Subject: [PATCH] radeon: add square-tiling flag
---
include/drm/radeon_drm.h |1 +
radeon/radeon_bo.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 728df60..ff97e48 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -808,6 +808,7 @@ struct drm_radeon_gem_create {
#define RADEON_TILING_SWAP_32BIT 0x8
#define RADEON_TILING_SURFACE 0x10 /* this object requires a surface
* when mapped - i.e. front buffer */
+#define RADEON_TILING_MICRO_SQUARE 0x20
struct drm_radeon_gem_set_tiling {
uint32_t handle;
diff --git a/radeon/radeon_bo.h b/radeon/radeon_bo.h
index 8859c2c..37478a0 100644
--- a/radeon/radeon_bo.h
+++ b/radeon/radeon_bo.h
@@ -36,6 +36,7 @@
/* bo object */
#define RADEON_BO_FLAGS_MACRO_TILE 1
#define RADEON_BO_FLAGS_MICRO_TILE 2
+#define RADEON_BO_FLAGS_MICRO_TILE_SQUARE 0x20
struct radeon_bo_manager;
struct radeon_cs;
--
1.6.3.3
[PATCH 0/2] drm/radeon/kms: add support for depth-only rendering and 3DC texture compression on R3xx-R5xx
Hi,
I'd like to propose two patches for kernel DRM.
Currently the R300 CS checker doesn't allow rendering with no color
buffer set. This is needed for depth-only rendering which is required
for rendering into depth textures to generate shadow maps. The first
attached patch removes this restriction by skipping checking the
colorbuffer if both ZB_BW_CNTL.FAST_FILL and
RB3D_BLENDCNTL.READ_ENABLE are disabled, and RB3D_COLOR_CHANNEL_MASK
is 0. When these bits are set, the hardware won't touch the
colorbuffer at all.
The second attached patch adds support for the 3DC texture compression
(formats ATI1N and ATI2N). The former has 64 bits per 4x4 pixel block
(same as DXT1) and is available on R4xx and up, and the latter has 128
bits per 4x4 pixel block (same as DXT3/5) and is available on R5xx.
This functionality can be exposed in OpenGL by
GL_EXT_texture_compression_latc and GL_ARB_texture_compression_rgtc,
which is part of OpenGL 3.0 and will most probably be implemented in
Mesa in future.
Frankly ATI1N can already be used as it occupies the same format bits
as TX_FMT_3_3_2 with the addition that TX_FORMAT2_n.TXFORMAT_MSB must
be set. The CS parser doesn't read the TXFORMAT_MSB bit at all, so it
always interprets the format as 3_3_2. If the MSB bit is set with the
second patch, the CS parser interprets any format as ATI1N, because
the other extended formats won't be used anyway as they are not
exposed by any graphics API. Let me know if you agree with this
behavior.
Please review.
Best regards
Marek Olšák
From 386484e581cf4df96e3a62318103bcaa610bb238 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Thu, 17 Dec 2009 06:02:28 +0100
Subject: [PATCH 1/2] drm/radeon/kms: allow rendering while no colorbuffer is set on r300
Because hardware cannot disable all colorbuffers directly to do depth-only
rendering, a user should:
- disable reading from a colorbuffer in blending
- disable fastfill
- set the color channel mask to 0 to prevent writing to a colorbuffer
---
drivers/gpu/drm/radeon/r100.c |4
drivers/gpu/drm/radeon/r100_track.h |4 +++-
drivers/gpu/drm/radeon/r300.c | 12
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 84e5df7..7172746 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2881,6 +2881,10 @@ int r100_cs_track_check(struct radeon_device *rdev, struct r100_cs_track *track)
for (i = 0; i track-num_cb; i++) {
if (track-cb[i].robj == NULL) {
+ if (!(track-fastfill || track-color_channel_mask ||
+ track-blend_read_enable)) {
+continue;
+ }
DRM_ERROR([drm] No buffer for color buffer %d !\n, i);
return -EINVAL;
}
diff --git a/drivers/gpu/drm/radeon/r100_track.h b/drivers/gpu/drm/radeon/r100_track.h
index 7188c37..b27a699 100644
--- a/drivers/gpu/drm/radeon/r100_track.h
+++ b/drivers/gpu/drm/radeon/r100_track.h
@@ -67,13 +67,15 @@ struct r100_cs_track {
unsigned immd_dwords;
unsigned num_arrays;
unsigned max_indx;
+ unsigned color_channel_mask;
struct r100_cs_track_array arrays[11];
struct r100_cs_track_cb cb[R300_MAX_CB];
struct r100_cs_track_cb zb;
struct r100_cs_track_texture textures[R300_TRACK_MAX_TEXTURE];
boolz_enabled;
boolseparate_cube;
-
+ boolfastfill;
+ boolblend_read_enable;
};
int r100_cs_track_check(struct radeon_device *rdev, struct r100_cs_track *track);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 83490c2..6a5d117 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -992,6 +992,18 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
}
ib[idx] = idx_value + ((u32)reloc-lobj.gpu_offset);
break;
+ case 0x4e0c:
+ /* RB3D_COLOR_CHANNEL_MASK */
+ track-color_channel_mask = idx_value;
+ break;
+ case 0x4d1c:
+ /* ZB_BW_CNTL */
+ track-fastfill = !!(idx_value (1 2));
+ break;
+ case 0x4e04:
+ /* RB3D_BLENDCNTL */
+ track-blend_read_enable = !!(idx_value (1 2));
+ break;
case 0x4be8:
/* valid register only on RV530 */
if (p-rdev-family == CHIP_RV530)
--
1.6.3.3
From e0d65186af2fbd6a73b3d4968347aee9e884f758 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sat, 19 Dec 2009 00:23:00 +0100
Subject: [PATCH 2/2] drm/radeom/kms: add 3DC compression support
There are 2 formats:
ATI1N: 64 bits per 4x4 block, one-channel format
ATI2N: 128 bits per 4x4 block, two-channel format
---
drivers/gpu/drm/radeon/r300.c | 18 ++
drivers/gpu/drm/radeon/r300_reg.h |1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 6a5d117..3f2cc9e 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -887,6 +887,14 @@ static int r300_packet0_check
