[Mesa3d-dev] [PATCH] mesa/st: fix crash when drawing stencil pixels outside the drawbuffer
Hi,
the attached patch fixes a possible crash in function draw_stencil_pixels in
mesa/state_tracker. I've also updated the list of formats we read from to
prevent an assertion failing later in the code.
This makes glean/depthStencil work on r300g and softpipe.
Best regards
Marek Olšák
From 2b79c8adc5a92410cdfe4ae8c15880a73f839159 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?=
Date: Sat, 31 Oct 2009 19:38:29 +0100
Subject: [PATCH] mesa/st: fix crash when drawing stencil pixels outside the drawbuffer
Also, add a missing depth-stencil format to the list of formats we want
to read from.
---
src/mesa/state_tracker/st_cb_drawpixels.c |6 ++
src/mesa/state_tracker/st_cb_texture.c|3 ++-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c b/src/mesa/state_tracker/st_cb_drawpixels.c
index 0a6bfcd..0699404 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -669,6 +669,12 @@ draw_stencil_pixels(GLcontext *ctx, GLint x, GLint y,
strb = st_renderbuffer(ctx->DrawBuffer->
Attachment[BUFFER_STENCIL].Renderbuffer);
+ /* Do not draw outside the drawbuffer */
+ if (x + width > ctx->DrawBuffer->Width)
+ width = ctx->DrawBuffer->Width - x;
+ if (y + height > ctx->DrawBuffer->Height)
+ height = ctx->DrawBuffer->Height - y;
+
if (st_fb_orientation(ctx->DrawBuffer) == Y_0_TOP) {
y = ctx->DrawBuffer->Height - y - height;
}
diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c
index 878a40f..6f287ff 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1309,7 +1309,8 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum target, GLint level,
srcX, srcY,
width, height);
- if (baseFormat == GL_DEPTH_COMPONENT &&
+ if ((baseFormat == GL_DEPTH_COMPONENT ||
+baseFormat == GL_DEPTH24_STENCIL8) &&
pf_is_depth_and_stencil(stImage->pt->format))
transfer_usage = PIPE_TRANSFER_READ_WRITE;
else
--
1.6.3.3
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: Add a PREDICATE register file.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 michal wrote: > Keith Whitwell pisze: >> On Fri, 2009-10-30 at 11:24 -0700, michal wrote: >> >>> +/* >>> + * Currently, the following constraints apply. >>> + * >>> + * - PredSwizzleXYZW is either set to identity or replicate. >>> + * - PredSrcIndex is 0. >>> + */ >>> >> Michal, >> >> This is looking a lot better. In terms of the above comment, is this >> talking about the semantics of PIPE_CAP_GPU3 ? Or is GPU3 supposed to >> do full PredSwizzle/PredSrcIndex, just we haven't implemented it >> somewhere (eg in tgsi_exec.c)? >> >> I'd think we want to either: >> - remove fields from the token so that the comment isn't necessary, >> - remove the comment and have GPU3 mean that the full semantics are >> available >> - come up with yet another cap bit to say whether or not full predicate >> semantics are implemented by a particular driver. >> >> Needless to say I don't like the last option, so I guess that means we >> need to decide now whether the full semantics in the token are in or >> out. >> >> How does SM3 fall on these issues? >> > The SM3 specification explicitly states that the predicate swizzle needs > to be either .xyzw or component replicate. The GL_MESA_gpu_program3 spec > allows arbitrary swizzles (there's nothing in the document that would > say otherwise). This is one of the areas still open for discussion. Nicolai was looking into whether R500 could do the arbitrary swizzles without too much work. If R500 can't handle it, then I'll add the restriction to the spec. > I say, rename PIPE_CAP_GPU3 to PIPE_CAP_SM3 to indicate predicates are > supported with the mentioned swizzle constraints. When the dust settles > on gpu_program3 spec, the state tracker will compensate for the lack of > arbitrary swizzles if needed. > > Also, add PIPE_CAP_MAX_PREDICATES to query the number of predicate > registers supported by the driver. That will allow us to remove the > `PredSrcIndex is 0' constraint. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrs4L4ACgkQX1gOwKyEAw/3iwCfcqECydkzG9yQtVnahtJI0zh6 RmMAn0nR1WCcW0vI2zdj7/scUglmhoP+ =jHxh -END PGP SIGNATURE- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Initial version of GL_MESA_gpu_program3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Whitwell wrote: > On Mon, 2009-10-19 at 16:05 -0700, Ian Romanick wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Version 2 of the extension spec has been posted: >> >> http://people.freedesktop.org/~idr/MESA_gpu_program3.txt >> >> Unless anyone has major comments or objections, I think it's time to >> circulate this to down-stream users (e.g., Wine). Who are the right >> contacts? > > Is the intention to fill the gap between where we are now and the NV > program4 extensions, or to start out on a new MESA-specific path which > would include later on a MESA_gpu_program4 extension? > > The question is relevant because of things like condition-codes which > are in the NV GPU4 extension. > - If this is an intermediate step on the way to NV GPU4, then we > should probably prefer condition-codes over predicates. > - If we expect to define a Mesa GPU4, then sticking with predicates is > fine. For right now, the intention is to target what shipping hardware that Mesa supports can do. :) R500 can't do NVIDIA-style condition codes. We can fake it on 965, but it some cases a single instruction would be expanded to a big pile of instructions. Eric keeps telling me that he's going to get NV_fragment_program running on 965, and that will give us a better idea of how much instruction expansion we'll see. He keeps find other fun things to work on, though. My expectation is that there will be a gpu_program4 follow-on, but it probably won't be for a while. I want to see if how well this works out for Wine, for example, before I commit to doing the work of gpu_program4. Coming with the gpu_program3 spec, even with all the "harvesting" I did from other specs, was a shocking amount of work. > I guess in either case the Mesa IR can opt to choose predicates over > cond-codes, but a great benefit of an extension like this is that we can > point at Mesa IR and say "the semantics of this language are documented > in MESA_gpu_program3". > > IE. if you're not intending to provide a Mesa SM4 extension, it might be > better to stick closer to the NV usage for SM3 also. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrs38gACgkQX1gOwKyEAw9PeACggPMDer/f9l4SCna4JT1vza+/ 3xYAoIuYpBV3At5Cqj9fWo9bKQUR7U5O =i1R6 -END PGP SIGNATURE- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Visable performance regression in sauerbraten game
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maxim Levitsky wrote: > Tested revision just before texformat-rework, and everything was fine, > after there few revisions that won't work, and then I notice significant > speed reduction, and hiccups. > > Tested with default settings + 800x600, Intel G965 Is there a specific test case or application that shows the regression? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrs3acACgkQX1gOwKyEAw8oFwCgiv04BtX59QOlQ/9YSZnkXp8n I/0Anihf4O3wQCmmcszj/3+meDHXGE58 =SAEd -END PGP SIGNATURE- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Visable performance regression in sauerbraten game
Tested revision just before texformat-rework, and everything was fine, after there few revisions that won't work, and then I notice significant speed reduction, and hiccups. Tested with default settings + 800x600, Intel G965 Best regards, Maxim Levitsky -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: Add a PREDICATE register file.
OK, looks good Michal. Go ahead and apply when you're ready. Keith From: michal [mic...@vmware.com] Sent: Saturday, October 31, 2009 2:12 AM To: Keith Whitwell Cc: mesa3d-dev Subject: Re: [Mesa3d-dev] [PATCH] gallium: Add a PREDICATE register file. michal pisze: > Keith Whitwell pisze: > >> On Fri, 2009-10-30 at 11:24 -0700, michal wrote: >> >> >>> +/* >>> + * Currently, the following constraints apply. >>> + * >>> + * - PredSwizzleXYZW is either set to identity or replicate. >>> + * - PredSrcIndex is 0. >>> + */ >>> >>> >> Michal, >> >> This is looking a lot better. In terms of the above comment, is this >> talking about the semantics of PIPE_CAP_GPU3 ? Or is GPU3 supposed to >> do full PredSwizzle/PredSrcIndex, just we haven't implemented it >> somewhere (eg in tgsi_exec.c)? >> >> I'd think we want to either: >> - remove fields from the token so that the comment isn't necessary, >> - remove the comment and have GPU3 mean that the full semantics are >> available >> - come up with yet another cap bit to say whether or not full predicate >> semantics are implemented by a particular driver. >> >> Needless to say I don't like the last option, so I guess that means we >> need to decide now whether the full semantics in the token are in or >> out. >> >> How does SM3 fall on these issues? >> >> >> >> > The SM3 specification explicitly states that the predicate swizzle needs > to be either .xyzw or component replicate. The GL_MESA_gpu_program3 spec > allows arbitrary swizzles (there's nothing in the document that would > say otherwise). > > I say, rename PIPE_CAP_GPU3 to PIPE_CAP_SM3 to indicate predicates are > supported with the mentioned swizzle constraints. When the dust settles > on gpu_program3 spec, the state tracker will compensate for the lack of > arbitrary swizzles if needed. > > Also, add PIPE_CAP_MAX_PREDICATES to query the number of predicate > registers supported by the driver. That will allow us to remove the > `PredSrcIndex is 0' constraint. > > Attached a proposed patch for that. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: Add a PREDICATE register file.
michal pisze:
Keith Whitwell pisze:
On Fri, 2009-10-30 at 11:24 -0700, michal wrote:
+/*
+ * Currently, the following constraints apply.
+ *
+ * - PredSwizzleXYZW is either set to identity or replicate.
+ * - PredSrcIndex is 0.
+ */
Michal,
This is looking a lot better. In terms of the above comment, is this
talking about the semantics of PIPE_CAP_GPU3 ? Or is GPU3 supposed to
do full PredSwizzle/PredSrcIndex, just we haven't implemented it
somewhere (eg in tgsi_exec.c)?
I'd think we want to either:
- remove fields from the token so that the comment isn't necessary,
- remove the comment and have GPU3 mean that the full semantics are
available
- come up with yet another cap bit to say whether or not full predicate
semantics are implemented by a particular driver.
Needless to say I don't like the last option, so I guess that means we
need to decide now whether the full semantics in the token are in or
out.
How does SM3 fall on these issues?
The SM3 specification explicitly states that the predicate swizzle needs
to be either .xyzw or component replicate. The GL_MESA_gpu_program3 spec
allows arbitrary swizzles (there's nothing in the document that would
say otherwise).
I say, rename PIPE_CAP_GPU3 to PIPE_CAP_SM3 to indicate predicates are
supported with the mentioned swizzle constraints. When the dust settles
on gpu_program3 spec, the state tracker will compensate for the lack of
arbitrary swizzles if needed.
Also, add PIPE_CAP_MAX_PREDICATES to query the number of predicate
registers supported by the driver. That will allow us to remove the
`PredSrcIndex is 0' constraint.
Attached a proposed patch for that.
>From 085a5e8c33b2ed6347de2e86d9e972d70438c014 Mon Sep 17 00:00:00 2001
From: Michal Krol
Date: Sat, 31 Oct 2009 09:09:26 +
Subject: [PATCH] gallium: Cleanup predicate and condition code TGSI tokens.
There is little point in having a special TGSI token just to handle
predicate register updates. Remove tgsi_dst_register_ext_predicate token
and instead use a new PREDICATE register file to update predicates.
Actually, the contents of the obsolete token are being moved
to tgsi_instruction_ext_predicate, where they should be
from the very beginning.
Remove the NVIDIA-specific condition code tokens -- nobody uses them
and they can be emulated with predicates if needed.
Introduce PIPE_CAP_SM3 that indicates whether a driver supports
SM3-level instructions, and in particular predicates.
Add PIPE_CAP_MAX_PREDICATE_REGISTERS that can be used to query the driver
how many predicate registers it supports (currently it would be 1).
---
src/gallium/include/pipe/p_defines.h |2 +
src/gallium/include/pipe/p_shader_tokens.h | 117 ---
2 files changed, 20 insertions(+), 99 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 52887ea..6a61aea 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -333,6 +333,8 @@ enum pipe_transfer_usage {
#define PIPE_CAP_MAX_VERTEX_TEXTURE_UNITS 26
#define PIPE_CAP_TGSI_CONT_SUPPORTED 27
#define PIPE_CAP_BLEND_EQUATION_SEPARATE 28
+#define PIPE_CAP_SM3 29 /*< Shader Model 3 supported */
+#define PIPE_CAP_MAX_PREDICATE_REGISTERS 30
/**
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index de338c4..d4c8aad 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -1,6 +1,7 @@
/**
*
* Copyright 2008 Tungsten Graphics, Inc., Cedar Park, Texas.
+ * Copyright 2009 VMware, Inc.
* All Rights Reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
@@ -25,8 +26,8 @@
*
**/
-#ifndef TGSI_TOKEN_H
-#define TGSI_TOKEN_H
+#ifndef P_SHADER_TOKENS_H
+#define P_SHADER_TOKENS_H
#ifdef __cplusplus
extern "C" {
@@ -79,6 +80,7 @@ enum tgsi_file_type {
TGSI_FILE_ADDRESS =6,
TGSI_FILE_IMMEDIATE =7,
TGSI_FILE_LOOP=8,
+ TGSI_FILE_PREDICATE =9,
TGSI_FILE_COUNT /**< how many TGSI_FILE_ types */
};
@@ -319,7 +321,6 @@ struct tgsi_instruction
* instruction, including the instruction word.
*/
-#define TGSI_INSTRUCTION_EXT_TYPE_NV0
#define TGSI_INSTRUCTION_EXT_TYPE_LABEL 1
#define TGSI_INSTRUCTION_EXT_TYPE_TEXTURE 2
#define TGSI_INSTRUCTION_EXT_TYPE_PREDICATE 3
@@ -332,9 +333,6 @@ struct tgsi_instruction_ext
};
/*
- * If tgsi_instruction_ext::Type is TGSI_INSTRUCTION_EXT_TYPE_NV, it should
- * be cast to tgsi_instruction_ext_nv.
- *
* If tgsi_instruction_ext::Type is TGSI_INSTRUCTION_EXT_TYPE_LABEL, it
* should be cast to tgsi_instruction_ext_label.
*
@@ -348,56 +346,11 @@ struct tgsi_instr
Re: [Mesa3d-dev] [PATCH] gallium: Add a PREDICATE register file.
Keith Whitwell pisze: > On Fri, 2009-10-30 at 11:24 -0700, michal wrote: > >> +/* >> + * Currently, the following constraints apply. >> + * >> + * - PredSwizzleXYZW is either set to identity or replicate. >> + * - PredSrcIndex is 0. >> + */ >> > > Michal, > > This is looking a lot better. In terms of the above comment, is this > talking about the semantics of PIPE_CAP_GPU3 ? Or is GPU3 supposed to > do full PredSwizzle/PredSrcIndex, just we haven't implemented it > somewhere (eg in tgsi_exec.c)? > > I'd think we want to either: > - remove fields from the token so that the comment isn't necessary, > - remove the comment and have GPU3 mean that the full semantics are > available > - come up with yet another cap bit to say whether or not full predicate > semantics are implemented by a particular driver. > > Needless to say I don't like the last option, so I guess that means we > need to decide now whether the full semantics in the token are in or > out. > > How does SM3 fall on these issues? > > > The SM3 specification explicitly states that the predicate swizzle needs to be either .xyzw or component replicate. The GL_MESA_gpu_program3 spec allows arbitrary swizzles (there's nothing in the document that would say otherwise). I say, rename PIPE_CAP_GPU3 to PIPE_CAP_SM3 to indicate predicates are supported with the mentioned swizzle constraints. When the dust settles on gpu_program3 spec, the state tracker will compensate for the lack of arbitrary swizzles if needed. Also, add PIPE_CAP_MAX_PREDICATES to query the number of predicate registers supported by the driver. That will allow us to remove the `PredSrcIndex is 0' constraint. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
