Re: [Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA -> GL_RGB
On Mit, 2011-05-04 at 11:22 -0700, Tristan Schmelcher wrote: > Interestingly I have just found out that this issue only happens after > the machine has done a suspend/resume. On a fresh boot prior to the > suspend/resume the performance is good. So I guess somehow the driver > is "forgetting" that it can take a faster path that doesn't go through > _mesa_texstore. Which means that it could easily be fixed in a later > version. But now that I have worked around the problem I probably > won't have time to delve any further. The Mesa driver is blissfully oblivious of suspend/resume. It sounds like you may be hitting something like the recent Linux kernel bug where it didn't properly restore PAT attributes on all CPUs on resume. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
2011/5/5 Mathias Fröhlich : > > Hi all, > > On Thursday, May 05, 2011 04:32:03 you wrote: >> Okay my guess at the problem is that: >> >> the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely >> on the base in the CB being the same as the texture BASE which it won't >> be in the case where we are rendering to mip sublevels. Though I've no idea >> how to workaround this without explicit flushes. > > Hmm, may be. > I also thought that the surface sync packet has some special case optimzations > for some of the probably often used flags that lead to that kind of behaviour. > > May be that 'flush all' in case of a new framebuffer target for these kind of > chips is again a good idea instead of the finegrained flush dest caches. > > May be Alex finds some undocumented ideas somewhere in his bag :). Apparently the CB/DB surface sync stuff has a number of issues on r6xx, so we should just use event_write flushes for CB/DB. A single event write flush takes care of all dst caches. Something like this untested patch perhaps: http://people.freedesktop.org/~agd5f/r600g_event_flush.diff Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
Hi all, On Thursday, May 05, 2011 04:32:03 you wrote: > Okay my guess at the problem is that: > > the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely > on the base in the CB being the same as the texture BASE which it won't > be in the case where we are rendering to mip sublevels. Though I've no idea > how to workaround this without explicit flushes. Hmm, may be. I also thought that the surface sync packet has some special case optimzations for some of the probably often used flags that lead to that kind of behaviour. May be that 'flush all' in case of a new framebuffer target for these kind of chips is again a good idea instead of the finegrained flush dest caches. May be Alex finds some undocumented ideas somewhere in his bag :). Greetings and thanks for looking into this! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r128 status
On Thu, May 5, 2011 at 12:46 AM, Patrick Baggett wrote: > All, > Is the ATI Rage128 DRI (r128) driver still supported? Does anyone happen to > know of the status? > Patrick It's supported in that patches are accepted and that it _probably_ still compiles. Rage128s aren't capable enough to really do much useful though. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
2011/5/5 Dave Airlie : >>> So to be honset I do not understand where the data sticks and what I need to >>> do to get it out. >>> May be that observations make sense for somebody else? >>> >> >> I've been staring at this I'm running out of good ideas, and even bad ideas. >> >> It really does seem like the TC has some invalid lines in it maybe, >> and they don't get >> invalidated. So when we render the first mipmap level it samples the >> level 0 image >> via the TC, and pulls in some of say the level 1 image, then we write >> the level 1 image >> with the CB, and go to sample the level 1 image to render the level 2 >> image. That >> sampling of the level 1 image fails, because although we've flush the >> dest cache, >> we haven't flushed the texture src cache. >> >> However saying that I can't find a secret incantation of flags to put >> in the correct place >> to make it work. I'll keep looking at it. > > Okay my guess at the problem is that: > > the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely > on the base in the CB being the same as the texture BASE which it won't > be in the case where we are rendering to mip sublevels. Though I've no idea > how to workaround this without explicit flushes. Still in fail land here, I also tried to play with this on my RV670 (x2 card), and I couldn't find a working r600g at all on this card in terms of passing fbo-generatemipmaps, so I think we've had a long term problem and SBU fixes may have just covered it up in some cases. Similiar to other debugging emitting CB1 + flush all works on this card as well. The attached patch makes it all "happy". Dave. hack Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] r128 status
All, Is the ATI Rage128 DRI (r128) driver still supported? Does anyone happen to know of the status? Patrick ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glproto changes
Yeah... so considering the comments in mesa-dev earlier today, I was really
surprised to see that glproto and dri2proto were tagged today. I think we need
to brownbag retract and rethink this.
These changes break API. I'm all for fixing the structs, but anything that
breaks API (or worse, protocol) certainly warrants much more than the +0.0.1
version bump. This also makes it impossible to build the current dev and
current stable with the same protos installed. I haven't looked at the details
specifically, but I suspect that it also changes what is on the wire, meaning
clients and the server may disagree depending on which glproto version they
were using. Is that the case? If not, can't we solve this with some creative
union{}ing?
Either way, I think we should retract the glproto 1.4.13 release until we can
get this straightened out.
On May 4, 2011, at 18:17, Dave Airlie wrote:
> So I wasn't watching and glproto broke its interface, and I think its bad.
>
> Why?
>
> You can no longer bisect things across this point without now moving glproto.
> glxproto.h:xGLXBufferSwapComplete was a released header file
> definition, you cannot go back and change history.
>
> This should have been handled with xGLXBufferSwapComplete2 struct that
> newer mesa and X server could would use
> instead of the older code. Old code would build against the old broken
> defintion but since its broken it wouldn't matter,
> and new code would build against the new fixed definition.
>
> This doesn't address the I need the latest glproto to build mesa and
> my distro doesn't have which concerns me less
> than the I can't bisect anymore and I fully agree with Jesse that the
> last time we tried using #ifdef for this sort of thing it led
> to a number of untested combos resulting in impossible to debug issues.
>
> Dave.
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
>> So to be honset I do not understand where the data sticks and what I need to >> do to get it out. >> May be that observations make sense for somebody else? >> > > I've been staring at this I'm running out of good ideas, and even bad ideas. > > It really does seem like the TC has some invalid lines in it maybe, > and they don't get > invalidated. So when we render the first mipmap level it samples the > level 0 image > via the TC, and pulls in some of say the level 1 image, then we write > the level 1 image > with the CB, and go to sample the level 1 image to render the level 2 > image. That > sampling of the level 1 image fails, because although we've flush the > dest cache, > we haven't flushed the texture src cache. > > However saying that I can't find a secret incantation of flags to put > in the correct place > to make it work. I'll keep looking at it. Okay my guess at the problem is that: the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely on the base in the CB being the same as the texture BASE which it won't be in the case where we are rendering to mip sublevels. Though I've no idea how to workaround this without explicit flushes. Dave. > > Dave. > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
2011/5/3 Mathias Fröhlich :
>
> Marek,
>
> On Tuesday, May 03, 2011 01:33:17 you wrote:
>> 2011/5/2 Mathias Fröhlich :
>> > I have again spent some more tries with different kinds of flushes on the
>> > rv635. What helps for the mipmap problem here is emitting a
>> > texture_barrier as well as flushing anything that covers the whole
>> > memory range and more than two arbitrary color buffers. !?!
>>
>> The texture barrier in u_gen_mipmap seems to be the proper fix
>> (texture_barrier can be NULL on other drivers though), but we should
>> first make sure it wouldn't be hiding a bug elsewhere (see Alex's email).
>
> Hmm, I am not sure about this. I already had that patch also.
>
> Correct me when I am wrong:
> In u_gen_mipmap, we call cso_set_framebuffer, which I expect to be aequivalent
> to switching rendering outputs to a different fbo. When I do the aequivalent
> from OpenGL level, I expect to have everything available from the previous
> bound fbo without the need for the texture barrier extension (I don't recall
> the exact name). True?
>
> Which led me to the to the conclusion that I do not want to use an explicit
> texture barrier in this case but need to have something that flushes
> implicitly
> on setting a new framebuffer state.
> True?
>
> That would have the advantage that we already know what bo range to flush
> instead of just the whole gpu memory like it is done and required for the
> texture barrier.
> That this does not work for the rv635 does not imply that other chips/drivers
> cannot make use of this additional knowledge.
> ... my two cents.
>
>
> Appart from my current expectation about the implicit flush semantics on the
> framebuffer state, some notes on what flush works and what not:
>
> The reason that the texture barrier works for me, is - by experimental
> software development - that the texture barrier flushes the whole memory range
> with the
>
> S_0085F0_TC_ACTION_ENA(1) | S_0085F0_CB_ACTION_ENA(1) |
> S_0085F0_CB0_DEST_BASE_ENA(1) |
> S_0085F0_CB1_DEST_BASE_ENA(1) |
> S_0085F0_CB2_DEST_BASE_ENA(1) |
> S_0085F0_CB3_DEST_BASE_ENA(1) |
> S_0085F0_CB4_DEST_BASE_ENA(1) |
> S_0085F0_CB5_DEST_BASE_ENA(1) |
> S_0085F0_CB6_DEST_BASE_ENA(1) |
> S_0085F0_CB7_DEST_BASE_ENA(1)
>
> bits.
> If I do the same in r600_context_flush_dest_caches instead of the cache flush
> and invalidate and reduce the flags to say
>
> S_0085F0_CB_ACTION_ENA(1) |
> S_0085F0_CB0_DEST_BASE_ENA(1) |
> S_0085F0_CB1_DEST_BASE_ENA(1)
>
> It works for me also, but
>
> S_0085F0_CB_ACTION_ENA(1) |
> S_0085F0_CB0_DEST_BASE_ENA(1)
>
> does not work.
>
> But that puzzled me. Note that there is no S_0085F0_TC_ACTION_ENA(1) enable in
> there, and also there is no second color buffer while rendering mipmaps to
> flush. Also the colorbuffer bo's are already flushed explicitly for their bo
> range in r600_context_flush_dest_caches with their apropriate flags and
> ranges.
>
> The observation was that as long as I have at least 2 arbitrary colorbuffer
> bits included in this PKT3_SURFACE_SYNC and the flush covers the whole gpu
> memory range, the mipmaps are correct. Setting any other
> {SMX,TC,VC}_ACTION_ENA(1) flags just did not matter for my setup.
>
> So to be honset I do not understand where the data sticks and what I need to
> do to get it out.
> May be that observations make sense for somebody else?
>
I've been staring at this I'm running out of good ideas, and even bad ideas.
It really does seem like the TC has some invalid lines in it maybe,
and they don't get
invalidated. So when we render the first mipmap level it samples the
level 0 image
via the TC, and pulls in some of say the level 1 image, then we write
the level 1 image
with the CB, and go to sample the level 1 image to render the level 2
image. That
sampling of the level 1 image fails, because although we've flush the
dest cache,
we haven't flushed the texture src cache.
However saying that I can't find a secret incantation of flags to put
in the correct place
to make it work. I'll keep looking at it.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glproto changes
On Thu, 5 May 2011 11:17:02 +1000 Dave Airlie wrote: > So I wasn't watching and glproto broke its interface, and I think its bad. > > Why? > > You can no longer bisect things across this point without now moving glproto. > glxproto.h:xGLXBufferSwapComplete was a released header file > definition, you cannot go back and change history. > > This should have been handled with xGLXBufferSwapComplete2 struct that > newer mesa and X server could would use > instead of the older code. Old code would build against the old broken > defintion but since its broken it wouldn't matter, > and new code would build against the new fixed definition. > > This doesn't address the I need the latest glproto to build mesa and > my distro doesn't have which concerns me less > than the I can't bisect anymore and I fully agree with Jesse that the > last time we tried using #ifdef for this sort of thing it led > to a number of untested combos resulting in impossible to debug issues. Yes, in hindsight I was too shellshocked by our previous experience with dri2 invalidate, ifdefs, and untested paths to even consider allowing new code to build with old proto. But breaking bisect is bad, no doubt. But in this case adding a separate struct is probably the right thing to do, and I'd be happy to do it if people are willing to put up with the churn (glproto 1.4.14, dri2proto 2.5 plus changes to Mesa and X to use the new struct). -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glproto changes
So I wasn't watching and glproto broke its interface, and I think its bad. Why? You can no longer bisect things across this point without now moving glproto. glxproto.h:xGLXBufferSwapComplete was a released header file definition, you cannot go back and change history. This should have been handled with xGLXBufferSwapComplete2 struct that newer mesa and X server could would use instead of the older code. Old code would build against the old broken defintion but since its broken it wouldn't matter, and new code would build against the new fixed definition. This doesn't address the I need the latest glproto to build mesa and my distro doesn't have which concerns me less than the I can't bisect anymore and I fully agree with Jesse that the last time we tried using #ifdef for this sort of thing it led to a number of untested combos resulting in impossible to debug issues. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxproto: make GLX swap event struct match spec
On Wed, 4 May 2011 17:49:37 -0700 Jesse Barnes wrote: > How about you look at git and see what happened last time? > > We added some dri2 proto requests, and people wanted to build with old > versions w/o the new requests. So they added some ifdefs but didn't > check all the combos (now not just old server/new server, but > multiplied by two) and things were broken for awhile, and it was easy > to get breakage without even noticing (I found several bugs for people > related to invalidation that were solely due to bad builds). (For those who don't want to look through git and the history: the problem is that making the builds use old and new means you can build client and server with different proto versions and not even notice. That makes debugging all the harder because everything seems to be ok but you're now taking untested paths on the client and/or server side due to #ifdefs and protocol mismatches.) -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxproto: make GLX swap event struct match spec
On Thu, 05 May 2011 09:32:46 +1000 Dave Airlie wrote: > On Wed, 2011-05-04 at 16:16 -0700, Jesse Barnes wrote: > > On Wed, 04 May 2011 15:17:31 -0700 > > Ian Romanick wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On 05/03/2011 12:21 PM, Jesse Barnes wrote: > > > > We only spec a 32 bit swap count, so drop the high sbc field. > > > > > > > > Signed-off-by: Jesse Barnes > > > > > > Is there any way we could do this and NOT break building older versions > > > of Mesa? I'd like to be able to build 7.9, 7.10, and master on my > > > system without having two different versions of glproto. > > > > > > > We did that the last time glproto bumped (kept the req at 1.4.10 and > > added ifdefs), but that added bugs that we didn't find for awhile, so I > > wanted to try to avoid it this time. Another option for you would be > > to build 7.9, 7.10, and master against different install roots with > > PKG_CONFIG_PATH set appropriately... > > > > How about you try again, with an increased emphasis on not adding bugs, > now that you know what you did wrong the first time? How about you look at git and see what happened last time? We added some dri2 proto requests, and people wanted to build with old versions w/o the new requests. So they added some ifdefs but didn't check all the combos (now not just old server/new server, but multiplied by two) and things were broken for awhile, and it was easy to get breakage without even noticing (I found several bugs for people related to invalidation that were solely due to bad builds). -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/15] mesa: make debugging state per-context
Reduce duplication of code and make the MESA_DEBUG
environment variable turn on GL_ARB_debug_output by default,
and use the same logic to determine whether to print
debugging output to the command-line.
---
src/mesa/main/errors.c | 71 ++-
1 files changed, 27 insertions(+), 44 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index 44ecf5d..e1d4ef1 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -735,6 +735,25 @@ _mesa_init_errors(struct gl_context *ctx)
{
int s, t, sev;
struct gl_client_debug *ClientIDs = &ctx->Debug.ClientIDs;
+ GLboolean debug;
+
+ /* Check the MESA_DEBUG environment variable.
+*/
+ {
+ char *env = _mesa_getenv("MESA_DEBUG");
+
+ /* In a debug build, we print warning messages *unless*
+ * MESA_DEBUG is 0. In a non-debug build, we don't
+ * print warning messages *unless* MESA_DEBUG is
+ * set *to any value*.
+ */
+#ifdef DEBUG
+ debug = (env != NULL && atoi(env) == 0) ? 0 : 1;
+#else
+ debug = (env != NULL) ? 1 : 0;
+#endif
+ }
+ ctx->Extensions.ARB_debug_output = debug;
ctx->Debug.Callback = NULL;
ctx->Debug.SyncOutput = GL_FALSE;
@@ -804,28 +823,10 @@ _mesa_log_api_error(struct gl_context *ctx,
gl_api_error id,
}
static void
-output_if_debug(const char *prefixString, const char *outputString,
-GLboolean newline)
+output_if_debug(struct gl_context *ctx, const char *prefixString,
+const char *outputString, GLboolean newline)
{
- static int debug = -1;
-
- /* Check the MESA_DEBUG environment variable if it hasn't
-* been checked yet. We only have to check it once...
-*/
- if (debug == -1) {
- char *env = _mesa_getenv("MESA_DEBUG");
-
- /* In a debug build, we print warning messages *unless*
- * MESA_DEBUG is 0. In a non-debug build, we don't
- * print warning messages *unless* MESA_DEBUG is
- * set *to any value*.
- */
-#ifdef DEBUG
- debug = (env != NULL && atoi(env) == 0) ? 0 : 1;
-#else
- debug = (env != NULL) ? 1 : 0;
-#endif
- }
+ GLboolean debug = ctx->Extensions.ARB_debug_output;
/* Now only print the string if we're required to do so. */
if (debug) {
@@ -891,7 +892,7 @@ flush_delayed_errors( struct gl_context *ctx )
ctx->ErrorDebugCount,
error_string(ctx->ErrorValue));
- output_if_debug("Mesa", s, GL_TRUE);
+ output_if_debug(ctx, "Mesa", s, GL_TRUE);
ctx->ErrorDebugCount = 0;
}
@@ -917,7 +918,7 @@ _mesa_warning( struct gl_context *ctx, const char
*fmtString, ... )
if (ctx)
flush_delayed_errors( ctx );
- output_if_debug("Mesa warning", str, GL_TRUE);
+ output_if_debug(ctx, "Mesa warning", str, GL_TRUE);
}
@@ -965,25 +966,7 @@ _mesa_problem( const struct gl_context *ctx,
const char *fmtString, ... )
void
_mesa_error( struct gl_context *ctx, GLenum error, const char *fmtString, ... )
{
- static GLint debug = -1;
-
- /* Check debug environment variable only once:
-*/
- if (debug == -1) {
- const char *debugEnv = _mesa_getenv("MESA_DEBUG");
-
-#ifdef DEBUG
- if (debugEnv && strstr(debugEnv, "silent"))
- debug = GL_FALSE;
- else
- debug = GL_TRUE;
-#else
- if (debugEnv)
- debug = GL_TRUE;
- else
- debug = GL_FALSE;
-#endif
- }
+ GLboolean debug = ctx->Extensions.ARB_debug_output;
if (debug) {
if (ctx->ErrorValue == error &&
@@ -1007,7 +990,7 @@ _mesa_error( struct gl_context *ctx, GLenum
error, const char *fmtString, ... )
if (len < MAXSTRING) {
_mesa_log_api_error(ctx, API_ERROR_UNKNOWN, len, s2);
-output_if_debug("Mesa: User error", s2, GL_TRUE);
+output_if_debug(ctx, "Mesa: User error", s2, GL_TRUE);
}
ctx->ErrorDebugFmtString = fmtString;
@@ -1035,7 +1018,7 @@ _mesa_debug( const struct gl_context *ctx, const
char *fmtString, ... )
va_start(args, fmtString);
_mesa_vsnprintf(s, MAXSTRING, fmtString, args);
va_end(args);
- output_if_debug("Mesa", s, GL_FALSE);
+ output_if_debug(ctx, "Mesa", s, GL_FALSE);
#endif /* DEBUG */
(void) ctx;
(void) fmtString;
--
1.7.0.4
From e7c380003806ff13e18297829e2f290ac6d46b4c Mon Sep 17 00:00:00 2001
From: nobled
Date: Wed, 4 May 2011 20:00:34 +
Subject: [PATCH 15/15] mesa: make debugging state per-context
Reduce duplication of code and make the MESA_DEBUG
environment variable turn on GL_ARB_debug_output by default,
and use the same logic to determine whether to print
debugging output to the command-line.
---
src/mesa/main/errors.c | 71 ++-
1 files changed, 27 insertions(+), 44 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index 44ecf5d..e1d4ef1 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -735,6 +735,25 @@ _mesa_
[Mesa-dev] [PATCH 12/15] mesa: implement the last of GL_ARB_debug_output
Store client-defined message IDs in a hash table,
and sort them by severity into three linked lists
so they can be selected by severity level later.
---
src/mesa/main/context.c |2 +
src/mesa/main/errors.c | 267 ++-
src/mesa/main/errors.h |3 +
3 files changed, 244 insertions(+), 28 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 0173535..6b82817 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1148,6 +1148,8 @@ _mesa_free_context_data( struct gl_context *ctx )
/* needs to be after freeing shared state */
_mesa_free_display_list_data(ctx);
+ _mesa_free_errors_data(ctx);
+
if (ctx->Extensions.String)
free((void *) ctx->Extensions.String);
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index a93137c..3a1d5a8 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -32,6 +32,7 @@
#include "imports.h"
#include "context.h"
+#include "hash.h"
#include "mtypes.h"
#include "version.h"
@@ -39,6 +40,12 @@
#define MAXSTRING MAX_DEBUG_MESSAGE_LENGTH
+struct gl_client_severity
+{
+ struct simple_node link;
+ GLuint ID;
+};
+
static char out_of_memory[] = "Debugging error: out of memory";
#define enum_is(e, kind1, kind2) \
@@ -114,6 +121,134 @@ enum_to_index(GLenum e)
};
}
+
+/*
+ * We store a bitfield in the hash table, with five possible values total.
+ *
+ * The ENABLED_BIT's purpose is self-explanatory.
+ *
+ * The FOUND_BIT is needed to differentiate the value of DISABLED from
+ * the value returned by HashTableLookup() when it can't find the given key.
+ *
+ * The KNOWN_SEVERITY bit is a bit complicated:
+ *
+ * A client may call Control() with an array of IDs, then call Control()
+ * on all message IDs of a certain severity, then Insert() one of the
+ * previously specified IDs, giving us a known severity level, then call
+ * Control() on all message IDs of a certain severity level again.
+ *
+ * After the first call, those IDs will have a FOUND_BIT, but will not
+ * exist in any severity-specific list, so the second call will not
+ * impact them. This is undesirable but unavoidable given the API:
+ * The only entrypoint that gives a severity for a client-defined ID
+ * is the Insert() call.
+ *
+ * For the sake of Control(), we want to maintain the invariant
+ * that an ID will either appear in none of the three severity lists,
+ * or appear once, to minimize pointless duplication and potential surprises.
+ *
+ * Because Insert() is the only place that will learn an ID's severity,
+ * it should insert an ID into the appropriate list, but only if the ID
+ * doesn't exist in it or any other list yet. Because searching all three
+ * lists at O(n) is needlessly expensive, we store KNOWN_SEVERITY.
+ */
+enum {
+#define FOUND_BIT (0x1 << 0)
+#define ENABLED_BIT(0x1 << 1)
+#define KNOWN_SEVERITY (0x1 << 2)
+/* HashTable reserves zero as a return value meaning 'not found' */
+NOT_FOUND = 0,
+DISABLED = FOUND_BIT,
+ENABLED = ENABLED_BIT | FOUND_BIT
+};
+
+/**
+ * Returns the state of the given message ID in a client-controlled
+ * namespace.
+ * 'source', 'type', and 'severity' are array indices like TYPE_ERROR,
+ * not GL enums.
+ */
+static GLboolean
+get_message_state(struct gl_context *ctx, int source, int type,
+ GLuint id, int severity)
+{
+ struct gl_client_namespace *nspace =
+ &ctx->Debug.ClientIDs.Namespaces[source][type];
+ uintptr_t state;
+
+ /* In addition to not being able to store zero as a value, HashTable also
+ can't use zero as a key. */
+ if (id)
+ state = (uintptr_t)_mesa_HashLookup(nspace->IDs, id);
+ else
+ state = nspace->ZeroID;
+
+ /* Only do this once for each ID. This makes sure the ID exists in,
+ at most, one list, and does not pointlessly appear multiple times. */
+ if (!(state & KNOWN_SEVERITY)) {
+ struct gl_client_severity *entry;
+
+ if (state == NOT_FOUND) {
+ if (ctx->Debug.ClientIDs.Defaults[severity][source][type])
+state = ENABLED;
+ else
+state = DISABLED;
+ }
+
+ entry = malloc(sizeof *entry);
+ if (!entry)
+ goto out;
+
+ state |= KNOWN_SEVERITY;
+
+ if (id)
+ _mesa_HashInsert(nspace->IDs, id, (void*)state);
+ else
+ nspace->ZeroID = state;
+
+ entry->ID = id;
+ insert_at_tail(&nspace->Severity[severity], &entry->link);
+ }
+
+out:
+ return !!(state & ENABLED_BIT);
+}
+
+/**
+ * Sets the state of the given message ID in a client-controlled
+ * namespace.
+ * 'source' and 'type' are array indices like TYPE_ERROR, not GL enums.
+ */
+static void
+set_message_state(struct gl_context *ctx, int source, int type,
+ GLuint id, GLboolean enabled)
+{
+ struct gl_client_namespace *nspace =
+ &ctx->Debug.ClientIDs.Namespaces[source][type];
+ uintptr_t state;
+
+ /* In addition to not being able
Re: [Mesa-dev] [PATCH 0/11] implement GL_ARB_debug_output
On Tue, May 3, 2011 at 7:33 PM, Brian Paul wrote: > On 05/02/2011 04:59 PM, nobled wrote: >> >> git repo: >> https://github.com/nobled/mesa.git >> (branch: arb_debug_output, rebased on >> bd661a933b18fccd7102d05932774ee61a90ec9e) >> >> web interface: >> https://github.com/nobled/mesa/commits/arb_debug_output >> >> spec: >> http://www.opengl.org/registry/specs/ARB/debug_output.txt >> >> This series adds almost everything needed to advertise the extension >> GL_ARB_debug_output. The only thing missing is the ability to pass an >> array of IDs to glDebugMessageControlARB with the parameter 'source' >> having the value GL_DEBUG_SOURCE_APPLICATION_ARB or >> GL_DEBUG_SOURCE_THIRD_PARTY_ARB. >> >> Since the *ControlARB stuff was the part I was least certain about, I >> also broke it up into even smaller patches. What I think is needed to >> fill in the missing functionality is a structure that works like C++'s >> std::map, with a GLuint/GLboolean key/value pair. There would also >> need to be, for each map, three std::set-like structures that record >> the HIGH, MEDIUM, and LOW-severity message IDs. Otherwise it wouldn't >> be possible for clients to make calls like this that impact all >> messages of a certain severity level: >> >> glDebugMessageControlARB(GL_DEBUG_SOURCE_APPLICATION_ARB, GL_DONT_CARE, >> GL_DEBUG_SEVERITY_LOW_ARB, 0, NULL, GL_TRUE); >> >> Does mesa have structures like those in the auxiliary code somewhere? >> Or is there a way to wrap the C++ STL in C code? > > To map GLuint to 'something' we typically use the hash table in hash.c > Otherwise, you could make something based on simple_list.h. I believe > we're talking about a pretty small set of GLuints, right? So linear search > wouldn't be a big deal? > > >> Open question: The app might pass 'implementation-dependent' message >> IDs to glDebugMessageControlARB that don't actually exist in mesa. The >> spec doesn't say whether we should give an error or silently ignore >> IDs like that. >> >> Also an open question: what to do when apps misbehave and send the >> same source/type/message ID tuple to glDebugMessageInsertARB twice or >> more, but with different severity levels each time, and then they call >> glDebugMessageControlARB on all messages with a certain severity. >> Should mesa use the latest-specified severity as the canonical one, or >> the first? > > I haven't even read the spec for this extension yet so I don't have any > answers for you. > > I did a quick review of your patches and they mostly look OK. I'll post > specific comments in a bit. > > It looks like almost all the changes are confined to errors.c and mtypes.h > so I'm not too worried about regressions or a big impact on the rest of the > code. > > I'm OK with you committing what you have and following up with changes > if/when the above questions get answered. > > -Brian > > Okay, I revised and rebased the branch on github based on your comments. Now there are several new patches implementing the final pieces and enabling the extension by default when the environment variable MESA_DEBUG is set (the same way it enables the current stderr debug messages). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxproto: make GLX swap event struct match spec
On Wed, 2011-05-04 at 16:16 -0700, Jesse Barnes wrote: > On Wed, 04 May 2011 15:17:31 -0700 > Ian Romanick wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 05/03/2011 12:21 PM, Jesse Barnes wrote: > > > We only spec a 32 bit swap count, so drop the high sbc field. > > > > > > Signed-off-by: Jesse Barnes > > > > Is there any way we could do this and NOT break building older versions > > of Mesa? I'd like to be able to build 7.9, 7.10, and master on my > > system without having two different versions of glproto. > > > > We did that the last time glproto bumped (kept the req at 1.4.10 and > added ifdefs), but that added bugs that we didn't find for awhile, so I > wanted to try to avoid it this time. Another option for you would be > to build 7.9, 7.10, and master against different install roots with > PKG_CONFIG_PATH set appropriately... > How about you try again, with an increased emphasis on not adding bugs, now that you know what you did wrong the first time? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxproto: make GLX swap event struct match spec
On Wed, 4 May 2011 16:16:37 -0700 Jesse Barnes wrote: > On Wed, 04 May 2011 15:17:31 -0700 > Ian Romanick wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 05/03/2011 12:21 PM, Jesse Barnes wrote: > > > We only spec a 32 bit swap count, so drop the high sbc field. > > > > > > Signed-off-by: Jesse Barnes > > > > Is there any way we could do this and NOT break building older versions > > of Mesa? I'd like to be able to build 7.9, 7.10, and master on my > > system without having two different versions of glproto. > > > > We did that the last time glproto bumped (kept the req at 1.4.10 and > added ifdefs), but that added bugs that we didn't find for awhile, so I > wanted to try to avoid it this time. Another option for you would be > to build 7.9, 7.10, and master against different install roots with > PKG_CONFIG_PATH set appropriately... Or just backport the fix to 7.x :) The server is only sending 32 bytes regardless, so having the fix in older client library versions will give either the right sbc number (if the server is new) or 0 if the server is old (unless you've wrapped the sbc_lo field and sbc_hi is set). So an improvement either way. -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxproto: make GLX swap event struct match spec
On Wed, 04 May 2011 15:17:31 -0700 Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/03/2011 12:21 PM, Jesse Barnes wrote: > > We only spec a 32 bit swap count, so drop the high sbc field. > > > > Signed-off-by: Jesse Barnes > > Is there any way we could do this and NOT break building older versions > of Mesa? I'd like to be able to build 7.9, 7.10, and master on my > system without having two different versions of glproto. > We did that the last time glproto bumped (kept the req at 1.4.10 and added ifdefs), but that added bugs that we didn't find for awhile, so I wanted to try to avoid it this time. Another option for you would be to build 7.9, 7.10, and master against different install roots with PKG_CONFIG_PATH set appropriately... -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Make swap event handling match the spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2011 12:21 PM, Jesse Barnes wrote: > Ian reminded me that we changed the spec to fit within an XEvent, but we > never updated the code to match. This set of patches (much simpler than > the last) does just that. Wrapping support can be added to Mesa if we > really want 64 bit values, but that means checking the drawable sbc and > adding whenver sbc hits 0. 3/4, 4/4, 5/6, and 6/6: Reviewed-by: Ian Romanick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3B0pAACgkQX1gOwKyEAw8JmwCeKgOPMC733wwz5zCP1OuSYX7f h+wAn05XZhh6akmfUyuaJ2THREQEaDsw =FzuP -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error building glxext.c
On May 4, 2011, at 11:04, Jesse Barnes wrote: > libGL is missing the change and version requirement bump, so you'll > have to use the last glproto release until I land the Mesa fix along > with a new glproto release. Sorry for the trouble; I pushed glproto > yesterday assuming I'd be able to push the other bits right away too, > but I'm still waiting for review. > > I'll revert the glproto commit today if it looks like I won't be able > to do the release. Nah. No need for reversion, un-reversion noise if it'll be fixed in the next few days. A few more red boxes in the tinderbox won't hurt so long as we know it's coming soon. We should just try better next time to coordinate pushes that are interdependent. Thanks, Jeremy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxproto: make GLX swap event struct match spec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> We only spec a 32 bit swap count, so drop the high sbc field.
>
> Signed-off-by: Jesse Barnes
Is there any way we could do this and NOT break building older versions
of Mesa? I'd like to be able to build 7.9, 7.10, and master on my
system without having two different versions of glproto.
> ---
> configure.ac |2 +-
> glxproto.h |3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index d88e6df..a3047e4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1,5 +1,5 @@
> AC_PREREQ([2.60])
> -AC_INIT([GLProto], [1.4.12],
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> +AC_INIT([GLProto], [1.4.13],
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> AM_INIT_AUTOMAKE([foreign dist-bzip2])
> AM_MAINTAINER_MODE
>
> diff --git a/glxproto.h b/glxproto.h
> index 0ff44e3..a6018a1 100644
> --- a/glxproto.h
> +++ b/glxproto.h
> @@ -1380,8 +1380,7 @@ typedef struct {
> CARD32 ust_lo B32;
> CARD32 msc_hi B32;
> CARD32 msc_lo B32;
> -CARD32 sbc_hi B32;
> -CARD32 sbc_lo B32;
> +CARD32 sbc B32;
> } xGLXBufferSwapComplete;
>
> //
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk3B0HsACgkQX1gOwKyEAw+27gCeLgSzv2Yjq7NQF+3QjeoXS8J0
qoQAn3n+Q8ujE3JFwpAyCM9TYtZ13wy0
=OkZ2
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxproto: make GLX swap event struct match spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2011 02:08 PM, Jesse Barnes wrote: > On Tue, 3 May 2011 14:02:31 -0700 > Jesse Barnes wrote: > >> On Tue, 03 May 2011 13:54:38 -0700 >> Keith Packard wrote: >> >>> On Tue, 3 May 2011 12:21:24 -0700, Jesse Barnes >>> wrote: >>> We only spec a 32 bit swap count, so drop the high sbc field. >>> >>> You're missing the explicit 16-bit padding field after 'event_type' >>> >>> The documented encoding >>> http://www.opengl.org/registry/specs/INTEL/swap_event.txt needs to be >>> fixed to match this, it has the padding at the end which leaves most of >>> the structure mis-aligned. >> >> Right, another case where we updated the spec incorrectly then failed >> to make the code match the broken definition (the complete enums also >> need to match the final values, which are correct in the first part of >> the spec). Yay for divergence. > > Fixed version below. > Does this need the "B16" cruft? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3BzwQACgkQX1gOwKyEAw/SowCfaAm1gxkowryhD2ku9oPMlaUY YyoAniZgXMFszpUBwnJH17JDyZwtsOw+ =k7tr -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: Verify that drawable creation on the client side actually worked
... and clean up if it didn't.
Signed-off-by: Adam Jackson
---
src/glx/glx_pbuffer.c | 76 -
src/glx/glxcmds.c | 74 +++-
2 files changed, 98 insertions(+), 52 deletions(-)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 5f91bc6..1d9c1e9 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -187,7 +187,7 @@ determineTextureFormat(const int *attribs, int numAttribs)
return 0;
}
-static void
+static GLboolean
CreateDRIDrawable(Display *dpy, struct glx_config *config,
XID drawable, XID glxdrawable,
const int *attrib_list, size_t num_attribs)
@@ -198,22 +198,24 @@ CreateDRIDrawable(Display *dpy, struct glx_config *config,
psc = priv->screens[config->screen];
if (psc->driScreen == NULL)
- return;
+ return GL_TRUE; /* not a DRI screen, not an error */
pdraw = psc->driScreen->createDrawable(psc, drawable,
glxdrawable, config);
if (pdraw == NULL) {
fprintf(stderr, "failed to create drawable\n");
- return;
+ return GL_FALSE;
}
if (__glxHashInsert(priv->drawHash, glxdrawable, pdraw)) {
(*pdraw->destroyDrawable) (pdraw);
- return; /* FIXME: Check what we're supposed to do here... */
+ return GL_FALSE;
}
pdraw->textureTarget = determineTextureTarget(attrib_list, num_attribs);
pdraw->textureFormat = determineTextureFormat(attrib_list, num_attribs);
+
+ return GL_TRUE;
}
static void
@@ -234,11 +236,12 @@ DestroyDRIDrawable(Display *dpy, GLXDrawable drawable,
int destroy_xdrawable)
#else
-static void
+static GLboolean
CreateDRIDrawable(Display *dpy, const struct glx_config * fbconfig,
XID drawable, XID glxdrawable,
const int *attrib_list, size_t num_attribs)
{
+return GL_FALSE;
}
static void
@@ -367,6 +370,27 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
return 0;
}
+static void
+protocolDestroyDrawable(Display *dpy, GLXDrawable drawable, CARD32 glxCode)
+{
+ xGLXDestroyPbufferReq *req;
+ CARD8 opcode;
+
+ opcode = __glXSetupForCommand(dpy);
+ if (!opcode)
+ return;
+
+ LockDisplay(dpy);
+
+ GetReq(GLXDestroyPbuffer, req);
+ req->reqType = opcode;
+ req->glxCode = glxCode;
+ req->pbuffer = (GLXPbuffer) drawable;
+
+ UnlockDisplay(dpy);
+ SyncHandle();
+}
+
/**
* Create a non-pbuffer GLX drawable.
*
@@ -378,6 +402,7 @@ CreateDrawable(Display *dpy, struct glx_config *config,
Drawable drawable, const int *attrib_list, CARD8 glxCode)
{
xGLXCreateWindowReq *req;
+ GLXDrawable ret;
CARD32 *data;
unsigned int i;
CARD8 opcode;
@@ -401,7 +426,7 @@ CreateDrawable(Display *dpy, struct glx_config *config,
req->screen = config->screen;
req->fbconfig = config->fbconfigID;
req->window = drawable;
- req->glxwindow = XAllocID(dpy);
+ req->glxwindow = ret = XAllocID(dpy);
req->numAttribs = i;
if (attrib_list)
@@ -410,9 +435,16 @@ CreateDrawable(Display *dpy, struct glx_config *config,
UnlockDisplay(dpy);
SyncHandle();
- CreateDRIDrawable(dpy, config, drawable, req->glxwindow, attrib_list, i);
+ if (!CreateDRIDrawable(dpy, config, drawable, ret, attrib_list, i)) {
+ if (glxCode == X_GLXCreatePixmap)
+ glxCode = X_GLXDestroyPixmap;
+ else
+ glxCode = X_GLXDestroyWindow;
+ protocolDestroyDrawable(dpy, ret, glxCode);
+ ret = None;
+ }
- return req->glxwindow;
+ return ret;
}
@@ -422,27 +454,11 @@ CreateDrawable(Display *dpy, struct glx_config *config,
static void
DestroyDrawable(Display * dpy, GLXDrawable drawable, CARD32 glxCode)
{
- xGLXDestroyPbufferReq *req;
- CARD8 opcode;
-
if ((dpy == NULL) || (drawable == 0)) {
return;
}
-
- opcode = __glXSetupForCommand(dpy);
- if (!opcode)
- return;
-
- LockDisplay(dpy);
-
- GetReq(GLXDestroyPbuffer, req);
- req->reqType = opcode;
- req->glxCode = glxCode;
- req->pbuffer = (GLXPbuffer) drawable;
-
- UnlockDisplay(dpy);
- SyncHandle();
+ protocolDestroyDrawable(dpy, drawable, glxCode);
DestroyDRIDrawable(dpy, drawable, GL_FALSE);
@@ -474,6 +490,7 @@ CreatePbuffer(Display * dpy, struct glx_config *config,
CARD8 opcode;
unsigned int i;
Pixmap pixmap;
+ GLboolean glx_1_3 = GL_FALSE;
i = 0;
if (attrib_list) {
@@ -492,6 +509,8 @@ CreatePbuffer(Display * dpy, struct glx_config *config,
xGLXCreatePbufferReq *req;
unsigned int extra = (size_in_attribs) ? 0 : 2;
+ glx_1_3 = GL_TRUE;
+
GetReqExtra(GLXCreatePbuffer, (8 * (i + extra)), req);
data = (CARD32 *) (req + 1);
@@ -536,7 +555,12 @@ CreatePbuffer(Display * dpy, struct glx_config *config,
pixmap = XCreatePixmap(dpy, RootWindow(dpy, config->screen),
width, height, config->rgbBit
Re: [Mesa-dev] [PATCH] Improve ONE_DIV_LN2 and M_PI constants
On Wed, May 4, 2011 at 3:25 PM, Matt Turner wrote: > On Thu, Dec 2, 2010 at 8:20 PM, Matt Turner wrote: >> On Wed, Dec 1, 2010 at 11:24 PM, Ian Romanick wrote: >>> On 12/01/2010 01:40 PM, Matt Turner wrote: 1/ln(2) is equivalent to log2(e), so define it as such. log2(e) = ln(e)/ln(2) = 1/ln(2) M_PI is updated to add some precision (value found in my math.h header). >>> >>> I wish I had noticed this when I added M_LOG2E. It seems better to >>> replace the single use of ONE_DIV_LN2 (in prog_statevars.c) with M_LOG2E. >> >> I think replacing ONE_DIV_LN2 with M_LOG2E in its single use makes the >> code harder to understand, especially since the next line is >> >> value[2] = (GLfloat)(ctx->Fog.Density * ONE_DIV_LN2); >> value[3] = (GLfloat)(ctx->Fog.Density * ONE_DIV_SQRT_LN2); >> >> It's not intuitively obvious that M_LOG2E == 1/ln(2), so I actually >> think the patch is good as is. >> >> Matt > > I never saw any response, so how about the two attached patches? They look fine to me. Reviewed-by: Alex Deucher > > Matt > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/14] i965: Update cached stencil region pointer when updating draw buffers
From: Chad Versace
That is, update brw_context.state.stencil_region and set the dirty bit
BRW_NEW_STENCIL_BUFFER.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_vtbl.c |8 +++-
src/mesa/drivers/dri/intel/intel_buffers.c |8 ++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 3bb8588..ccd1f8a 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -101,13 +101,19 @@ static void brw_set_draw_region( struct intel_context
*intel,
{
struct brw_context *brw = brw_context(&intel->ctx);
- assert(!stencil_region);
+ assert(stencil_region == NULL || intel->has_hiz);
if (brw->state.depth_region != depth_region) {
brw->state.dirty.brw |= BRW_NEW_DEPTH_BUFFER;
intel_region_release(&brw->state.depth_region);
intel_region_reference(&brw->state.depth_region, depth_region);
}
+
+ if (brw->state.stencil_region != stencil_region) {
+ brw->state.dirty.brw |= BRW_NEW_STENCIL_BUFFER;
+ intel_region_release(&brw->state.stencil_region);
+ intel_region_reference(&brw->state.stencil_region, stencil_region);
+ }
}
diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
b/src/mesa/drivers/dri/intel/intel_buffers.c
index 0857b8a..1a7142e 100644
--- a/src/mesa/drivers/dri/intel/intel_buffers.c
+++ b/src/mesa/drivers/dri/intel/intel_buffers.c
@@ -91,7 +91,9 @@ void
intel_draw_buffer(struct gl_context * ctx, struct gl_framebuffer *fb)
{
struct intel_context *intel = intel_context(ctx);
- struct intel_region *colorRegions[MAX_DRAW_BUFFERS], *depthRegion = NULL;
+ struct intel_region *colorRegions[MAX_DRAW_BUFFERS];
+ struct intel_region *depthRegion = NULL;
+ struct intel_region *stencilRegion = NULL; /* Separate stencil region. */
struct intel_renderbuffer *irbDepth = NULL, *irbStencil = NULL;
bool fb_has_hiz = intel_framebuffer_has_hiz(fb);
@@ -194,6 +196,7 @@ intel_draw_buffer(struct gl_context * ctx, struct
gl_framebuffer *fb)
if (irbStencil && irbStencil->region) {
if (fb_has_hiz) {
assert(irbStencil->Base.Format == MESA_FORMAT_S8);
+stencilRegion = irbStencil->region;
} else {
assert(irbStencil->Base.Format == MESA_FORMAT_S8_Z24);
}
@@ -214,6 +217,7 @@ intel_draw_buffer(struct gl_context * ctx, struct
gl_framebuffer *fb)
if (!fb_has_hiz && !depthRegion && irbStencil && irbStencil->region)
depthRegion = irbStencil->region;
+
/*
* Update depth and stencil test state
*/
@@ -232,7 +236,7 @@ intel_draw_buffer(struct gl_context * ctx, struct
gl_framebuffer *fb)
intel->NewGLState |= (_NEW_DEPTH | _NEW_STENCIL);
}
- intel->vtbl.set_draw_region(intel, colorRegions, depthRegion, NULL,
+ intel->vtbl.set_draw_region(intel, colorRegions, depthRegion, stencilRegion,
fb->_NumColorDrawBuffers);
intel->NewGLState |= _NEW_BUFFERS;
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/14] intel: Change signature of intel_context.vtbl.set_draw_region
From: Chad Versace
Add additional parameter 'struct intel_region *stencil_region'.
A subsequent patch uses the new parameter to update
brw_context.state.stencil_region.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i915/i915_vtbl.c |3 +++
src/mesa/drivers/dri/i965/brw_vtbl.c |3 +++
src/mesa/drivers/dri/intel/intel_buffers.c |2 +-
src/mesa/drivers/dri/intel/intel_context.h |1 +
4 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index 820feba..b3a3958 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -555,6 +555,7 @@ static void
i915_set_draw_region(struct intel_context *intel,
struct intel_region *color_regions[],
struct intel_region *depth_region,
+ struct intel_region *stencil_region,
GLuint num_regions)
{
struct i915_context *i915 = i915_context(&intel->ctx);
@@ -565,6 +566,8 @@ i915_set_draw_region(struct intel_context *intel,
struct i915_hw_state *state = &i915->state;
uint32_t draw_x, draw_y, draw_offset;
+ assert(!stencil_region);
+
if (state->draw_region != color_regions[0]) {
intel_region_release(&state->draw_region);
intel_region_reference(&state->draw_region, color_regions[0]);
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index fc98c92..3bb8588 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -96,10 +96,13 @@ static void brw_destroy_context( struct intel_context
*intel )
static void brw_set_draw_region( struct intel_context *intel,
struct intel_region *color_regions[],
struct intel_region *depth_region,
+ struct intel_region *stencil_region,
GLuint num_color_regions)
{
struct brw_context *brw = brw_context(&intel->ctx);
+ assert(!stencil_region);
+
if (brw->state.depth_region != depth_region) {
brw->state.dirty.brw |= BRW_NEW_DEPTH_BUFFER;
intel_region_release(&brw->state.depth_region);
diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
b/src/mesa/drivers/dri/intel/intel_buffers.c
index 7167207..0857b8a 100644
--- a/src/mesa/drivers/dri/intel/intel_buffers.c
+++ b/src/mesa/drivers/dri/intel/intel_buffers.c
@@ -232,7 +232,7 @@ intel_draw_buffer(struct gl_context * ctx, struct
gl_framebuffer *fb)
intel->NewGLState |= (_NEW_DEPTH | _NEW_STENCIL);
}
- intel->vtbl.set_draw_region(intel, colorRegions, depthRegion,
+ intel->vtbl.set_draw_region(intel, colorRegions, depthRegion, NULL,
fb->_NumColorDrawBuffers);
intel->NewGLState |= _NEW_BUFFERS;
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index 770febe..a7e372b 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -135,6 +135,7 @@ struct intel_context
void (*set_draw_region) (struct intel_context * intel,
struct intel_region * draw_regions[],
struct intel_region * depth_region,
+ struct intel_region * stencil_region,
GLuint num_regions);
void (*reduced_primitive_state) (struct intel_context * intel,
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/14] i965: Define tracked state for separate stencil buffer
From: Chad Versace
- Add field brw_context.state.stencil_region.
- Define dirty bit BRW_NEW_STENCIL_BUFFER, which signals that
brw_context.state.stencil_region has changed.
- Define 'struct brw_tracked_state brw_stencil_buffer' and add it to
gen4_atoms.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_context.h |5 +++
src/mesa/drivers/dri/i965/brw_misc_state.c | 45 ++
src/mesa/drivers/dri/i965/brw_state.h|1 +
src/mesa/drivers/dri/i965/brw_state_upload.c |2 +
src/mesa/drivers/dri/i965/brw_vtbl.c |1 +
5 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 26cd820..4e1cb0b 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -146,6 +146,8 @@ struct brw_context;
#define BRW_NEW_INDEX_BUFFER 0x10
#define BRW_NEW_VS_CONSTBUF0x20
#define BRW_NEW_WM_CONSTBUF0x40
+/** \see brw_context.state.stencil_region */
+#define BRW_NEW_STENCIL_BUFFER 0x80
struct brw_state_flags {
/** State update flags signalled by mesa internals */
@@ -482,6 +484,9 @@ struct brw_context
/** \see struct brw_tracked_state brw_depthbuffer */
struct intel_region *depth_region;
+ /** \see struct brw_tracked_state brw_stencil_buffer */
+ struct intel_region *stencil_region;
+
/** \} */
/**
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 874a1d5..972d6c5 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -326,7 +326,52 @@ const struct brw_tracked_state brw_depthbuffer = {
.emit = emit_depthbuffer,
};
+static void prepare_stencil_buffer(struct brw_context *brw)
+{
+ struct intel_region *region = brw->state.stencil_region;
+
+ if (region != NULL) {
+ /* Separate stencil can only be used when HiZ is enabled. */
+ assert(intel_framebuffer_has_hiz(brw->intel.ctx.DrawBuffer));
+
+ brw_add_validated_bo(brw, region->buffer);
+ }
+}
+
+static void emit_stencil_buffer(struct brw_context *brw)
+{
+ struct intel_context *intel = &brw->intel;
+ struct intel_region *region = brw->state.stencil_region;
+ uint32_t length = 3;
+ uint32_t bias = 2;
+
+ if (region == NULL)
+ return;
+
+ /* Separate stencil can only be used when HiZ is enabled. */
+ assert(intel_framebuffer_has_hiz(brw->intel.ctx.DrawBuffer));
+ BEGIN_BATCH(length);
+ OUT_BATCH((_3DSTATE_STENCIL_BUFFER << 16) | (length - bias));
+ OUT_BATCH(region->pitch * region->cpp - 1);
+ OUT_RELOC(region->buffer,
+ I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
+ 0);
+ ADVANCE_BATCH();
+}
+
+/**
+ * \see brw_context.state.stencil_region
+ */
+const struct brw_tracked_state brw_stencil_buffer = {
+ .dirty = {
+ .mesa = 0,
+ .brw = BRW_NEW_STENCIL_BUFFER | BRW_NEW_BATCH,
+ .cache = 0,
+ },
+ .prepare = prepare_stencil_buffer,
+ .emit = emit_stencil_buffer,
+};
/***
* Polygon stipple packet
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index 8b9e3a4..55e65a4 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -72,6 +72,7 @@ extern const struct brw_tracked_state brw_sf_prog;
extern const struct brw_tracked_state brw_sf_unit;
extern const struct brw_tracked_state brw_sf_vp;
extern const struct brw_tracked_state brw_state_base_address;
+extern const struct brw_tracked_state brw_stencil_buffer;
extern const struct brw_tracked_state brw_urb_fence;
extern const struct brw_tracked_state brw_vertex_state;
extern const struct brw_tracked_state brw_vs_surfaces;
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 008aceb..bc24f75 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -88,6 +88,7 @@ static const struct brw_tracked_state *gen4_atoms[] =
&brw_blend_constant_color,
&brw_depthbuffer,
+ &brw_stencil_buffer,
&brw_polygon_stipple,
&brw_polygon_stipple_offset,
@@ -309,6 +310,7 @@ static struct dirty_bit_map brw_bits[] = {
DEFINE_BIT(BRW_NEW_NR_VS_SURFACES),
DEFINE_BIT(BRW_NEW_VS_CONSTBUF),
DEFINE_BIT(BRW_NEW_WM_CONSTBUF),
+ DEFINE_BIT(BRW_NEW_STENCIL_BUFFER),
{0, 0, 0}
};
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 4939e97..fc98c92 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -73,6 +73,7 @@ static void brw_destroy_context( struct intel_context *intel )
}
intel_region_release(&brw->state.depth_region);
+ intel_region_rel
[Mesa-dev] [PATCH 11/14] i965: Emit 3D_STATE_HIER_DEPTH_BUFFER
From: Chad Versace
... when a HiZ region is present. Also change the hiz bits and depth
format in 3D_STATE_DEPTH_BUFFER.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 47 +---
1 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 8d1832d..874a1d5 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -32,6 +32,7 @@
#include "intel_batchbuffer.h"
+#include "intel_fbo.h"
#include "intel_regions.h"
#include "brw_context.h"
@@ -188,15 +189,21 @@ const struct brw_tracked_state brw_psp_urb_cbs = {
static void prepare_depthbuffer(struct brw_context *brw)
{
struct intel_region *depth_region = brw->state.depth_region;
+ struct intel_region *hiz_region =
+ intel_framebuffer_get_hiz_region(brw->intel.ctx.DrawBuffer);
if (depth_region != NULL)
brw_add_validated_bo(brw, depth_region->buffer);
+ if (hiz_region != NULL)
+ brw_add_validated_bo(brw, hiz_region->buffer);
}
static void emit_depthbuffer(struct brw_context *brw)
{
struct intel_context *intel = &brw->intel;
struct intel_region *depth_region = brw->state.depth_region;
+ struct intel_region *hiz_region =
+ intel_framebuffer_get_hiz_region(intel->ctx.DrawBuffer);
unsigned int len;
if (intel->gen >= 6)
@@ -232,8 +239,12 @@ static void emit_depthbuffer(struct brw_context *brw)
case 4:
if (intel->depth_buffer_is_float)
format = BRW_DEPTHFORMAT_D32_FLOAT;
-else
- format = BRW_DEPTHFORMAT_D24_UNORM_S8_UINT;
+else {
+ if (hiz_region)
+ format = BRW_DEPTHFORMAT_D24_UNORM_X8_UINT;
+ else
+ format = BRW_DEPTHFORMAT_D24_UNORM_S8_UINT;
+}
break;
default:
assert(0);
@@ -241,11 +252,18 @@ static void emit_depthbuffer(struct brw_context *brw)
}
assert(depth_region->tiling != I915_TILING_X);
- assert(intel->gen < 6 || depth_region->tiling == I915_TILING_Y);
+ /*
+ * If HiZ is enabled on Gen5, then Y tiling must be used. See Vol 2,
+ * Section 11.5.6.1 3DSTATE_DEPTH_BUFFER, Bit 1.27 "Tiled Surface".
+ */
+ assert((intel->gen < 6 && !hiz_region)
+ || depth_region->tiling == I915_TILING_Y);
BEGIN_BATCH(len);
OUT_BATCH(_3DSTATE_DEPTH_BUFFER << 16 | (len - 2));
OUT_BATCH(((depth_region->pitch * depth_region->cpp) - 1) |
+ ((hiz_region ? 1 : 0) << 21) | /* hiearchical depth buffer
enable */
+ ((hiz_region ? 1 : 0) << 22) | /* separate stencil buffer
enable */
(format << 18) |
(BRW_TILEWALK_YMAJOR << 26) |
((depth_region->tiling != I915_TILING_NONE) << 27) |
@@ -267,8 +285,27 @@ static void emit_depthbuffer(struct brw_context *brw)
ADVANCE_BATCH();
}
- /* Initialize it for safety. */
- if (intel->gen >= 6) {
+ /* Emit batch for HiZ buffer. */
+ if (hiz_region) {
+ BEGIN_BATCH(3);
+ OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
+ OUT_BATCH(hiz_region->pitch * hiz_region->cpp - 1);
+ OUT_RELOC(hiz_region->buffer,
+I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
+0);
+ ADVANCE_BATCH();
+ }
+
+ /*
+* Emit clear params for safety.
+*
+* If hiz is enabled, then clear params must be emitted. From Vol 2,
+* Section 11.5.6.4.1 3DSTATE_CLEAR_PARAMS:
+* [DevIL], [DevSNB] 3DSTATE_CLEAR_PARAMS packet must follow the
+* DEPTH_BUFFER_STATE packet when HiZ is enabled and the
DEPTH_BUFFER_STATE
+* changes.
+*/
+ if (intel->gen >= 6 || hiz_region) {
BEGIN_BATCH(2);
OUT_BATCH(_3DSTATE_CLEAR_PARAMS << 16 | (2 - 2));
OUT_BATCH(0);
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/14] i965: Refactor prepare_depthbuffer() and emit_depthbuffer()
From: Chad Versace
Rename variable 'region' to 'depth_region'. This removes naming ambiguity
introduced by the next commit, which introduces the variable 'hiz_region'.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 7119786..8d1832d 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -187,16 +187,16 @@ const struct brw_tracked_state brw_psp_urb_cbs = {
static void prepare_depthbuffer(struct brw_context *brw)
{
- struct intel_region *region = brw->state.depth_region;
+ struct intel_region *depth_region = brw->state.depth_region;
- if (region != NULL)
- brw_add_validated_bo(brw, region->buffer);
+ if (depth_region != NULL)
+ brw_add_validated_bo(brw, depth_region->buffer);
}
static void emit_depthbuffer(struct brw_context *brw)
{
struct intel_context *intel = &brw->intel;
- struct intel_region *region = brw->state.depth_region;
+ struct intel_region *depth_region = brw->state.depth_region;
unsigned int len;
if (intel->gen >= 6)
@@ -206,7 +206,7 @@ static void emit_depthbuffer(struct brw_context *brw)
else
len = 5;
- if (region == NULL) {
+ if (depth_region == NULL) {
BEGIN_BATCH(len);
OUT_BATCH(_3DSTATE_DEPTH_BUFFER << 16 | (len - 2));
OUT_BATCH((BRW_DEPTHFORMAT_D32_FLOAT << 18) |
@@ -225,7 +225,7 @@ static void emit_depthbuffer(struct brw_context *brw)
} else {
unsigned int format;
- switch (region->cpp) {
+ switch (depth_region->cpp) {
case 2:
format = BRW_DEPTHFORMAT_D16_UNORM;
break;
@@ -240,22 +240,22 @@ static void emit_depthbuffer(struct brw_context *brw)
return;
}
- assert(region->tiling != I915_TILING_X);
- assert(intel->gen < 6 || region->tiling == I915_TILING_Y);
+ assert(depth_region->tiling != I915_TILING_X);
+ assert(intel->gen < 6 || depth_region->tiling == I915_TILING_Y);
BEGIN_BATCH(len);
OUT_BATCH(_3DSTATE_DEPTH_BUFFER << 16 | (len - 2));
- OUT_BATCH(((region->pitch * region->cpp) - 1) |
+ OUT_BATCH(((depth_region->pitch * depth_region->cpp) - 1) |
(format << 18) |
(BRW_TILEWALK_YMAJOR << 26) |
- ((region->tiling != I915_TILING_NONE) << 27) |
+ ((depth_region->tiling != I915_TILING_NONE) << 27) |
(BRW_SURFACE_2D << 29));
- OUT_RELOC(region->buffer,
+ OUT_RELOC(depth_region->buffer,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
0);
OUT_BATCH((BRW_SURFACE_MIPMAPLAYOUT_BELOW << 1) |
- ((region->width - 1) << 6) |
- ((region->height - 1) << 19));
+ ((depth_region->width - 1) << 6) |
+ ((depth_region->height - 1) << 19));
OUT_BATCH(0);
if (intel->is_g4x || intel->gen >= 5)
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/14] intel: Refactor the wrapping of textures with renderbuffers
From: Chad Versace
The update of the wrapping renderbuffer's region was done in
intel_renderbuffer_texture(). Move the update into intel_update_wrapper(),
which is a more logical location for updates.
The next commits allocates and updates the texture's hiz region in
intel_update_wrapper(), and having the two region updates in the same
function makes good form.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 7e3f698..d20009e 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -397,6 +397,8 @@ static GLboolean
intel_update_wrapper(struct gl_context *ctx, struct intel_renderbuffer *irb,
struct gl_texture_image *texImage)
{
+ struct intel_texture_image *intel_image = intel_texture_image(texImage);
+
if (!intel_span_supports_format(texImage->TexFormat)) {
DBG("Render to texture BAD FORMAT %s\n",
_mesa_get_format_name(texImage->TexFormat));
@@ -415,6 +417,12 @@ intel_update_wrapper(struct gl_context *ctx, struct
intel_renderbuffer *irb,
irb->Base.Delete = intel_delete_renderbuffer;
irb->Base.AllocStorage = intel_nop_alloc_storage;
+ /* Point the renderbuffer's region to the texture's region. */
+ if (irb->region != intel_image->mt->region) {
+ intel_region_release(&irb->region);
+ intel_region_reference(&irb->region, intel_image->mt->region);
+ }
+
return GL_TRUE;
}
@@ -520,13 +528,6 @@ intel_render_texture(struct gl_context * ctx,
att->Texture->Name, newImage->Width, newImage->Height,
irb->Base.RefCount);
- /* point the renderbufer's region to the texture image region */
- if (irb->region != intel_image->mt->region) {
- if (irb->region)
-intel_region_release(&irb->region);
- intel_region_reference(&irb->region, intel_image->mt->region);
- }
-
intel_set_draw_offset_for_image(intel_image, att->Zoffset);
intel_image->used_as_render_target = GL_TRUE;
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/14] i965: Change FBO completeness criteria when HiZ is enabled
From: Chad Versace
When HiZ is enabled, hardware allows rendering to a separate stencil
region and does not allow rendering to a combined depth/stencil region.
So we need to:
1. Set an FBO's status to GL_FRAMEBUFFER_UNSUPPORTED when HiZ is enabled
and its depth and stencil attachments are identical or share the same
texture target.
2. Fix the logic in intel_draw_buffer() that expects combined
depth/stencil.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |3 +-
src/mesa/drivers/dri/intel/intel_buffers.c | 19 ++
src/mesa/drivers/dri/intel/intel_fbo.c | 41 +
src/mesa/drivers/dri/intel/intel_span.c |1 +
4 files changed, 39 insertions(+), 25 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 47b8b51..28c9562 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -125,7 +125,8 @@ brw_render_target_supported(gl_format format)
/* These are not color render targets like the table holds, but we
* ask the question for FBO completeness.
*/
- if (format == MESA_FORMAT_S8_Z24 ||
+ if (format == MESA_FORMAT_S8 ||
+ format == MESA_FORMAT_S8_Z24 ||
format == MESA_FORMAT_X8_Z24 ||
format == MESA_FORMAT_Z16) {
return true;
diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
b/src/mesa/drivers/dri/intel/intel_buffers.c
index ee551ef..7167207 100644
--- a/src/mesa/drivers/dri/intel/intel_buffers.c
+++ b/src/mesa/drivers/dri/intel/intel_buffers.c
@@ -93,6 +93,7 @@ intel_draw_buffer(struct gl_context * ctx, struct
gl_framebuffer *fb)
struct intel_context *intel = intel_context(ctx);
struct intel_region *colorRegions[MAX_DRAW_BUFFERS], *depthRegion = NULL;
struct intel_renderbuffer *irbDepth = NULL, *irbStencil = NULL;
+ bool fb_has_hiz = intel_framebuffer_has_hiz(fb);
if (!fb) {
/* this can happen during the initial context initialization */
@@ -166,13 +167,15 @@ intel_draw_buffer(struct gl_context * ctx, struct
gl_framebuffer *fb)
/***
*** Get depth buffer region and check if we need a software fallback.
-*** Note that the depth buffer is usually a DEPTH_STENCIL buffer.
***/
if (fb->_DepthBuffer && fb->_DepthBuffer->Wrapped) {
irbDepth = intel_renderbuffer(fb->_DepthBuffer->Wrapped);
if (irbDepth && irbDepth->region) {
FALLBACK(intel, INTEL_FALLBACK_DEPTH_BUFFER, GL_FALSE);
depthRegion = irbDepth->region;
+
+ /* Combined depth/stencil formats cannot be used with HiZ. */
+ assert(!fb_has_hiz || irbDepth->Base.Format != MESA_FORMAT_S8_Z24);
}
else {
FALLBACK(intel, INTEL_FALLBACK_DEPTH_BUFFER, GL_TRUE);
@@ -185,15 +188,15 @@ intel_draw_buffer(struct gl_context * ctx, struct
gl_framebuffer *fb)
depthRegion = NULL;
}
- /***
-*** Stencil buffer
-*** This can only be hardware accelerated if we're using a
-*** combined DEPTH_STENCIL buffer.
-***/
+ /* Stencil buffer */
if (fb->_StencilBuffer && fb->_StencilBuffer->Wrapped) {
irbStencil = intel_renderbuffer(fb->_StencilBuffer->Wrapped);
if (irbStencil && irbStencil->region) {
- ASSERT(irbStencil->Base.Format == MESA_FORMAT_S8_Z24);
+ if (fb_has_hiz) {
+assert(irbStencil->Base.Format == MESA_FORMAT_S8);
+ } else {
+assert(irbStencil->Base.Format == MESA_FORMAT_S8_Z24);
+ }
FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_FALSE);
}
else {
@@ -208,7 +211,7 @@ intel_draw_buffer(struct gl_context * ctx, struct
gl_framebuffer *fb)
/* If we have a (packed) stencil buffer attached but no depth buffer,
* we still need to set up the shared depth/stencil state so we can use it.
*/
- if (depthRegion == NULL && irbStencil && irbStencil->region)
+ if (!fb_has_hiz && !depthRegion && irbStencil && irbStencil->region)
depthRegion = irbStencil->region;
/*
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 42dcf7a..1b67917 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -642,22 +642,31 @@ intel_validate_framebuffer(struct gl_context *ctx, struct
gl_framebuffer *fb)
const struct intel_renderbuffer *stencilRb =
intel_get_renderbuffer(fb, BUFFER_STENCIL);
int i;
-
- if (depthRb && stencilRb && stencilRb != depthRb) {
- if (fb->Attachment[BUFFER_DEPTH].Type == GL_TEXTURE &&
- fb->Attachment[BUFFER_STENCIL].Type == GL_TEXTURE &&
- (fb->Attachment[BUFFER_DEPTH].Texture->Name ==
- fb->Attachment[BUFFER_STENCIL].Texture->Name)) {
-/* OK */
- } else {
-/* we only support combined depth/stencil buffers, not separate
- * stencil buffers.
-
[Mesa-dev] [PATCH 08/14] intel: Add hiz_region to intel_mipmap_tree
From: Chad Versace
When a depth texture is attached to an FBO, that texture's hiz surface
must be stored in the texture and not in the wrapping renderbuffer. If it
were stored in the renderbuffer, then inconsistent rendering would occur
when the depth texture was simultaneously attached to multiple FBO's.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c | 22 ++
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |1 +
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 13 +
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index d20009e..42dcf7a 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -397,6 +397,7 @@ static GLboolean
intel_update_wrapper(struct gl_context *ctx, struct intel_renderbuffer *irb,
struct gl_texture_image *texImage)
{
+ struct intel_context *intel = intel_context(ctx);
struct intel_texture_image *intel_image = intel_texture_image(texImage);
if (!intel_span_supports_format(texImage->TexFormat)) {
@@ -423,6 +424,27 @@ intel_update_wrapper(struct gl_context *ctx, struct
intel_renderbuffer *irb,
intel_region_reference(&irb->region, intel_image->mt->region);
}
+ /* Allocate the texture's hiz region if necessary. */
+ if (intel->vtbl.is_hiz_depth_format(intel, texImage->TexFormat)
+ && !intel_image->mt->hiz_region) {
+ intel_image->mt->hiz_region =
+ intel_region_alloc(intel->intelScreen,
+I915_TILING_Y,
+_mesa_get_format_bytes(texImage->TexFormat),
+texImage->Width,
+texImage->Height,
+GL_TRUE);
+ if (!intel_image->mt->hiz_region)
+ return GL_FALSE;
+ assert(intel_image->mt->hiz_region->buffer);
+ }
+
+ /* Point the renderbuffer's hiz region to the texture's hiz region. */
+ if (irb->hiz_region != intel_image->mt->hiz_region) {
+ intel_region_release(&irb->hiz_region);
+ intel_region_reference(&irb->hiz_region, intel_image->mt->hiz_region);
+ }
+
return GL_TRUE;
}
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index a340927..e62905d 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -200,6 +200,7 @@ intel_miptree_release(struct intel_context *intel,
DBG("%s deleting %p\n", __FUNCTION__, *mt);
intel_region_release(&((*mt)->region));
+ intel_region_release(&((*mt)->hiz_region));
for (i = 0; i < MAX_TEXTURE_LEVELS; i++) {
free((*mt)->level[i].x_offset);
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
index 760a8bc..5458adc 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
@@ -113,6 +113,19 @@ struct intel_mipmap_tree
*/
struct intel_region *region;
+ /**
+* This points to an auxillary hiz region if
+* 1. The texture has been attached to an FBO as a depthbuffer.
+* 2. The texture format is hiz compatible.
+* 3. The intel context supports hiz, of course.
+*
+* The hiz region is stored here instead of the wrapping intel_renderbuffer
+* because a single texture may be attached to multiple FBO's.
+*
+* \see intel_fbo.c:intel_wrap_texture()
+*/
+ struct intel_region *hiz_region;
+
/* These are also refcounted:
*/
GLuint refcount;
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/14] intel: Add hiz_region to intel_renderbuffer
From: Chad Versace
A hiz surface must be supplied to the hardware when rendering to a depth
buffer with hiz. There are three potential places to store that surface:
1. Allocate a larger intel_region for the depthbuffer, and let the
region's tail be the hiz surface.
2. Allocate a separate intel_region for hiz, and store it as
brw_context state.
3. Allocate a separate intel_region for hiz, and store it in
intel_renderbuffer.
We choose method 3.
Method 1 has not been chosen due to future complications it might cause
when requesting a DRI drawable's depth buffer attachment from X.
Method 2 has not been chosen because storing the hiz region apart from
the depth region makes lazy hiz/depth resolves difficult to implement.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c | 20
src/mesa/drivers/dri/intel/intel_fbo.h | 27 +++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index d539942..7e3f698 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -79,6 +79,9 @@ intel_delete_renderbuffer(struct gl_renderbuffer *rb)
if (intel && irb->region) {
intel_region_release(&irb->region);
}
+ if (intel && irb->hiz_region) {
+ intel_region_release(&irb->hiz_region);
+ }
free(irb);
}
@@ -146,6 +149,9 @@ intel_alloc_renderbuffer_storage(struct gl_context * ctx,
struct gl_renderbuffer
if (irb->region) {
intel_region_release(&irb->region);
}
+ if (irb->hiz_region) {
+ intel_region_release(&irb->hiz_region);
+ }
/* allocate new memory region/renderbuffer */
@@ -170,6 +176,20 @@ intel_alloc_renderbuffer_storage(struct gl_context * ctx,
struct gl_renderbuffer
ASSERT(irb->region->buffer);
+ if (intel->vtbl.is_hiz_depth_format(intel, rb->Format)) {
+ irb->hiz_region = intel_region_alloc(intel->intelScreen,
+ I915_TILING_Y,
+ irb->region->cpp,
+ irb->region->width,
+ irb->region->height,
+ GL_TRUE);
+ if (!irb->hiz_region) {
+ intel_region_release(&irb->region);
+ return GL_FALSE;
+ }
+ assert(irb->hiz_region->buffer);
+ }
+
rb->Width = width;
rb->Height = height;
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.h
b/src/mesa/drivers/dri/intel/intel_fbo.h
index 028f657..212dd9a 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.h
+++ b/src/mesa/drivers/dri/intel/intel_fbo.h
@@ -28,6 +28,7 @@
#ifndef INTEL_FBO_H
#define INTEL_FBO_H
+#include
#include "main/formats.h"
#include "intel_screen.h"
@@ -40,6 +41,9 @@ struct intel_renderbuffer
{
struct gl_renderbuffer Base;
struct intel_region *region;
+
+ /** Only used by depth renderbuffers for which HiZ is enabled. */
+ struct intel_region *hiz_region;
};
@@ -80,6 +84,29 @@ intel_get_renderbuffer(struct gl_framebuffer *fb, int
attIndex)
return NULL;
}
+/**
+ * If the framebuffer has a depth buffer attached, then return its HiZ region.
+ * The HiZ region may be null.
+ */
+static INLINE struct intel_region*
+intel_framebuffer_get_hiz_region(struct gl_framebuffer *fb)
+{
+ struct intel_renderbuffer *rb = NULL;
+ if (fb)
+ rb = intel_get_renderbuffer(fb, BUFFER_DEPTH);
+
+ if (rb)
+ return rb->hiz_region;
+ else
+ return NULL;
+}
+
+static INLINE bool
+intel_framebuffer_has_hiz(struct gl_framebuffer *fb)
+{
+ return intel_framebuffer_get_hiz_region(fb) != NULL;
+}
+
extern void
intel_renderbuffer_set_region(struct intel_context *intel,
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/14] intel: Change supported texture formats in intel_context for HiZ
From: Chad Versace In table intel_contex.ctx.TextureFormatsSupported, enable support for X8_Z24 unconditionally and enable support for S8 when hardware supports HiZ. These formats are necessary because HiZ requires separate depth and stencil buffers. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/intel/intel_context.c|5 + src/mesa/drivers/dri/intel/intel_fbo.c|5 - src/mesa/drivers/dri/intel/intel_tex_format.c |1 + 3 files changed, 10 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index d91a300..4866d41 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -716,7 +716,12 @@ intelInitContext(struct intel_context *intel, ctx->TextureFormatSupported[MESA_FORMAT_AL88] = GL_TRUE; if (intel->gen >= 4) ctx->TextureFormatSupported[MESA_FORMAT_AL1616] = GL_TRUE; + + /* Depth and stencil */ + ctx->TextureFormatSupported[MESA_FORMAT_X8_Z24] = GL_TRUE; ctx->TextureFormatSupported[MESA_FORMAT_S8_Z24] = GL_TRUE; + ctx->TextureFormatSupported[MESA_FORMAT_S8] = intel->has_hiz; + /* * This was disabled in initial FBO enabling to avoid combinations * of depth+stencil that wouldn't work together. We since decided diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c index ad2468a..d539942 100644 --- a/src/mesa/drivers/dri/intel/intel_fbo.c +++ b/src/mesa/drivers/dri/intel/intel_fbo.c @@ -129,7 +129,10 @@ intel_alloc_renderbuffer_storage(struct gl_context * ctx, struct gl_renderbuffer case GL_STENCIL_INDEX8_EXT: case GL_STENCIL_INDEX16_EXT: /* These aren't actual texture formats, so force them here. */ - rb->Format = MESA_FORMAT_S8_Z24; + if (intel->has_hiz) + rb->Format = MESA_FORMAT_S8; + else + rb->Format = MESA_FORMAT_S8_Z24; break; } diff --git a/src/mesa/drivers/dri/intel/intel_tex_format.c b/src/mesa/drivers/dri/intel/intel_tex_format.c index befa615..6890a69 100644 --- a/src/mesa/drivers/dri/intel/intel_tex_format.c +++ b/src/mesa/drivers/dri/intel/intel_tex_format.c @@ -22,6 +22,7 @@ intel_mesa_format_to_rb_datatype(gl_format format) case MESA_FORMAT_RGB565: case MESA_FORMAT_ARGB1555: case MESA_FORMAT_ARGB: + case MESA_FORMAT_S8: return GL_UNSIGNED_BYTE; case MESA_FORMAT_R16: case MESA_FORMAT_RG1616: -- 1.7.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/14] mesa/main: Add MESA_FORMAT_X8_Z24 to _mesa_choose_tex_format
From: Chad Versace Prefer MESA_FORMAT_X8_Z24 over MESA_FORMAT_S8_Z24 for textures with internal format GL_DEPTH_COMPONENT*. i965 needs MESA_FORMAT_X8_Z24 for HiZ. Signed-off-by: Chad Versace --- src/mesa/main/texformat.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c index 456687b..8cbb021 100644 --- a/src/mesa/main/texformat.c +++ b/src/mesa/main/texformat.c @@ -217,10 +217,12 @@ _mesa_choose_tex_format( struct gl_context *ctx, GLint internalFormat, case GL_DEPTH_COMPONENT24: case GL_DEPTH_COMPONENT32: RETURN_IF_SUPPORTED(MESA_FORMAT_Z32); + RETURN_IF_SUPPORTED(MESA_FORMAT_X8_Z24); RETURN_IF_SUPPORTED(MESA_FORMAT_S8_Z24); break; case GL_DEPTH_COMPONENT16: RETURN_IF_SUPPORTED(MESA_FORMAT_Z16); + RETURN_IF_SUPPORTED(MESA_FORMAT_X8_Z24); RETURN_IF_SUPPORTED(MESA_FORMAT_S8_Z24); default: ; /* fallthrough */ -- 1.7.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/14] intel: Add is_hiz_depth_format() to intel_contex.vtbl
From: Chad Versace
Given a format, is_hiz_depth_format() indicates if HiZ can be enabled on
a depthbuffer of that format.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i915/i915_vtbl.c |9 +
src/mesa/drivers/dri/i965/brw_vtbl.c | 11 +++
src/mesa/drivers/dri/intel/intel_context.h |4
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index 89650b6..820feba 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -687,6 +687,14 @@ i915_assert_not_dirty( struct intel_context *intel )
(void) dirty;
}
+/** Return false; i915 does not support HiZ. */
+static bool
+i915_is_hiz_depth_format(struct intel_context *intel,
+ gl_format format)
+{
+ return false;
+}
+
void
i915InitVtbl(struct i915_context *i915)
{
@@ -702,4 +710,5 @@ i915InitVtbl(struct i915_context *i915)
i915->intel.vtbl.assert_not_dirty = i915_assert_not_dirty;
i915->intel.vtbl.finish_batch = intel_finish_vb;
i915->intel.vtbl.render_target_supported = i915_render_target_supported;
+ i915->intel.vtbl.is_hiz_depth_format = i915_is_hiz_depth_format;
}
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index f2c417d..4939e97 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -149,6 +149,16 @@ static void brw_invalidate_state( struct intel_context
*intel, GLuint new_state
/* nothing */
}
+/**
+ * \see intel_context.vtbl.is_hiz_depth_format
+ */
+static bool brw_is_hiz_depth_format(struct intel_context *intel,
+gl_format format)
+{
+ /* In the future this will support other formats such as Z_FLOAT32. */
+ return intel->has_hiz && format == MESA_FORMAT_X8_Z24;
+}
+
void brwInitVtbl( struct brw_context *brw )
{
@@ -165,4 +175,5 @@ void brwInitVtbl( struct brw_context *brw )
brw->intel.vtbl.set_draw_region = brw_set_draw_region;
brw->intel.vtbl.debug_batch = brw_debug_batch;
brw->intel.vtbl.render_target_supported = brw_render_target_supported;
+ brw->intel.vtbl.is_hiz_depth_format = brw_is_hiz_depth_format;
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index 629279f..770febe 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -149,6 +149,10 @@ struct intel_context
void (*debug_batch)(struct intel_context *intel);
bool (*render_target_supported)(gl_format format);
+
+ /** Can HiZ be enabled on a depthbuffer of the given format? */
+ bool (*is_hiz_depth_format)(struct intel_context *intel,
+ gl_format format);
} vtbl;
GLbitfield Fallback; /**< mask of INTEL_FALLBACK_x bits */
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/14] intel: Override intel_context.has_hiz with env var INTEL_HIZ
From: Chad Versace
Valid values for INTEL_HIZ are "0" or "1".
Overriding HiZ is useful for performance profiling and testing.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_context.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index b1907f5..d91a300 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -609,6 +609,29 @@ intelInitDriverFunctions(struct dd_function_table
*functions)
intel_init_syncobj_functions(functions);
}
+/**
+ * \brief Override intel->has_hiz with environment variable INTEL_HIZ.
+ *
+ * Valid values for INTEL_HIZ are "0" and "1". If an invalid valid value is
+ * encountered, a warning is emitted and INTEL_HIZ is ignored.
+ */
+static void
+intel_override_hiz(struct intel_context *intel)
+{
+ const char *s = getenv("INTEL_HIZ");
+ if (!s) {
+ return;
+ } else if (!strncmp("0", s, 2)) {
+ intel->has_hiz = false;
+ } else if (!strncmp("1", s, 2)) {
+ intel->has_hiz = true;
+ } else {
+ _mesa_warning(&intel->ctx,
+"env variable INTEL_HIZ=\"%s\" has invalid value and "
+"is ignored", s);
+ }
+}
+
GLboolean
intelInitContext(struct intel_context *intel,
@@ -677,6 +700,8 @@ intelInitContext(struct intel_context *intel,
}
}
+ intel_override_hiz(intel);
+
memset(&ctx->TextureFormatSupported, 0,
sizeof(ctx->TextureFormatSupported));
ctx->TextureFormatSupported[MESA_FORMAT_ARGB] = GL_TRUE;
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/14] intel: Add flag intel_context.has_hiz
From: Chad Versace
Currently, it is always set it to false. Once the HiZ implementation is
complete, it needs to be enabled on Gen >= 5.
Even though HiZ support is present only on gen >= 5, the field belongs
in intel_context, not brw_context, because the functions that interact
with DRI2 and choose buffer formats are passed an intel_context.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_context.c |2 ++
src/mesa/drivers/dri/intel/intel_context.h |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index acdf35f..b1907f5 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -656,9 +656,11 @@ intelInitContext(struct intel_context *intel,
if (IS_GEN6(intel->intelScreen->deviceID)) {
intel->needs_ff_sync = GL_TRUE;
intel->has_luminance_srgb = GL_TRUE;
+ /* FINISHME: On Gen6, intel->has_hiz = GL_TRUE; */
} else if (IS_GEN5(intel->intelScreen->deviceID)) {
intel->needs_ff_sync = GL_TRUE;
intel->has_luminance_srgb = GL_TRUE;
+ /* FINISHME: On Gen5, intel->has_hiz = GL_TRUE; */
} else if (IS_965(intel->intelScreen->deviceID)) {
if (IS_G4X(intel->intelScreen->deviceID)) {
intel->has_luminance_srgb = GL_TRUE;
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index d3a8a65..629279f 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -166,6 +166,7 @@ struct intel_context
GLboolean is_945;
GLboolean has_luminance_srgb;
GLboolean has_xrgb_textures;
+ GLboolean has_hiz;
int urb_size;
--
1.7.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/14] i965: Begin hiz
From: Chad Versace With this patch series, depth writes, tests, and reads all work when rendering to an FBO with renderbuffer attachments. I have not yet tested the same when rendering to an FBO with texture attachments. This series differ from my first hiz series in that hiz enablement is a property of the renderbuffer rather than the context. I also added support for rendering to depth textures with hiz, though I haven't wrote the Piglit tests for that yet. I obtained the following piglit results on Gen5 with `env INTEL_HIZ=1`: pass: general/hiz pass: hiz/hiz-depth-test-fbo-d24 pass: hiz/hiz-depth-test-fbo-d24-s8 pass: hiz/hiz-depth-test-fbo-d24s8 crash: hiz/hiz-depth-test-stencil0 crash: hiz/hiz-depth-test-stencil1 And the test results when INTEL_HIZ is unset: pass: general/hiz pass: hiz/hiz-depth-test-fbo-d24 skip: hiz/hiz-depth-test-fbo-d24-s8 pass: hiz/hiz-depth-test-fbo-d24s8 crash: hiz/hiz-depth-test-stencil0 crash: hiz/hiz-depth-test-stencil1 (The crashes are not particular to my patches; master also crashes on those tests.) These patches live on my public hiz branch. Chad Versace (14): intel: Add flag intel_context.has_hiz intel: Override intel_context.has_hiz with env var INTEL_HIZ intel: Add is_hiz_depth_format() to intel_contex.vtbl mesa/main: Add MESA_FORMAT_X8_Z24 to _mesa_choose_tex_format intel: Change supported texture formats in intel_context for HiZ intel: Add hiz_region to intel_renderbuffer intel: Refactor the wrapping of textures with renderbuffers intel: Add hiz_region to intel_mipmap_tree i965: Change FBO completeness criteria when HiZ is enabled i965: Refactor prepare_depthbuffer() and emit_depthbuffer() i965: Emit 3D_STATE_HIER_DEPTH_BUFFER i965: Define tracked state for separate stencil buffer intel: Change signature of intel_context.vtbl.set_draw_region i965: Update cached stencil region pointer when updating draw buffers src/mesa/drivers/dri/i915/i915_vtbl.c| 12 ++ src/mesa/drivers/dri/i965/brw_context.h |5 + src/mesa/drivers/dri/i965/brw_misc_state.c | 118 ++ src/mesa/drivers/dri/i965/brw_state.h|1 + src/mesa/drivers/dri/i965/brw_state_upload.c |2 + src/mesa/drivers/dri/i965/brw_vtbl.c | 21 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |3 +- src/mesa/drivers/dri/intel/intel_buffers.c | 27 +++-- src/mesa/drivers/dri/intel/intel_context.c | 32 ++ src/mesa/drivers/dri/intel/intel_context.h |6 + src/mesa/drivers/dri/intel/intel_fbo.c | 103 +++- src/mesa/drivers/dri/intel/intel_fbo.h | 27 + src/mesa/drivers/dri/intel/intel_mipmap_tree.c |1 + src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 13 +++ src/mesa/drivers/dri/intel/intel_span.c |1 + src/mesa/drivers/dri/intel/intel_tex_format.c|1 + src/mesa/main/texformat.c|2 + 17 files changed, 322 insertions(+), 53 deletions(-) -- 1.7.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error building glxext.c
On 05/04/2011 09:35 AM, Dan McCabe wrote: > I followed the installation/build directions described here: > http://wiki.x.org/wiki/ModularDevelopersGuide > and I grabbed the src from git last night (early evening). As a first step, I would check if Mesa builds successfully independently of a full X build. That is, > git clone git://anongit.freedesktop.org/git/mesa/mesa.git > cd mesa > ./autogen.sh --stuff > make There's no need to do the full X build if you're just working on Mesa. -- Chad Versace c...@chad-versace.us ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Improve ONE_DIV_LN2 and M_PI constants
On Thu, Dec 2, 2010 at 8:20 PM, Matt Turner wrote: > On Wed, Dec 1, 2010 at 11:24 PM, Ian Romanick wrote: >> On 12/01/2010 01:40 PM, Matt Turner wrote: >>> 1/ln(2) is equivalent to log2(e), so define it as such. >>> >>> log2(e) = ln(e)/ln(2) = 1/ln(2) >>> >>> M_PI is updated to add some precision (value found in my math.h header). >> >> I wish I had noticed this when I added M_LOG2E. It seems better to >> replace the single use of ONE_DIV_LN2 (in prog_statevars.c) with M_LOG2E. > > I think replacing ONE_DIV_LN2 with M_LOG2E in its single use makes the > code harder to understand, especially since the next line is > > value[2] = (GLfloat)(ctx->Fog.Density * ONE_DIV_LN2); > value[3] = (GLfloat)(ctx->Fog.Density * ONE_DIV_SQRT_LN2); > > It's not intuitively obvious that M_LOG2E == 1/ln(2), so I actually > think the patch is good as is. > > Matt I never saw any response, so how about the two attached patches? Matt From 00e72b8eff5726517f623d9f61efa018fc41b1d8 Mon Sep 17 00:00:00 2001 From: Matt Turner Date: Wed, 4 May 2011 15:22:42 -0400 Subject: [PATCH 1/2] Replace ONE_DIV_LN2 constant with M_LOG2E 1/ln(2) is equivalent to log2(e), so define it as such. log2(e) = ln(e)/ln(2) = 1/ln(2) Signed-off-by: Matt Turner --- src/mesa/main/compiler.h |4 src/mesa/program/prog_statevars.c |2 +- 2 files changed, 1 insertions(+), 5 deletions(-) diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h index e17fd0f..81e08a0 100644 --- a/src/mesa/main/compiler.h +++ b/src/mesa/main/compiler.h @@ -366,10 +366,6 @@ static INLINE GLuint CPU_TO_LE32(GLuint x) #define M_LOG2E (1.4426950408889634074) #endif -#ifndef ONE_DIV_LN2 -#define ONE_DIV_LN2 (1.442695040888963456) -#endif - #ifndef ONE_DIV_SQRT_LN2 #define ONE_DIV_SQRT_LN2 (1.201122408786449815) #endif diff --git a/src/mesa/program/prog_statevars.c b/src/mesa/program/prog_statevars.c index d94d7fe..16f9690 100644 --- a/src/mesa/program/prog_statevars.c +++ b/src/mesa/program/prog_statevars.c @@ -459,7 +459,7 @@ _mesa_fetch_state(struct gl_context *ctx, const gl_state_index state[], value[0] = (ctx->Fog.End == ctx->Fog.Start) ? 1.0f : (GLfloat)(-1.0F / (ctx->Fog.End - ctx->Fog.Start)); value[1] = ctx->Fog.End * -value[0]; - value[2] = (GLfloat)(ctx->Fog.Density * ONE_DIV_LN2); + value[2] = (GLfloat)(ctx->Fog.Density * M_LOG2E); /* M_LOG2E == 1/ln(2) */ value[3] = (GLfloat)(ctx->Fog.Density * ONE_DIV_SQRT_LN2); return; -- 1.7.3.4 From dc6c6dd7f0f168c9233e637871d54f04f1fc7266 Mon Sep 17 00:00:00 2001 From: Matt Turner Date: Wed, 4 May 2011 15:23:43 -0400 Subject: [PATCH 2/2] Add precision to M_PI constant Value found in my math.h header. Signed-off-by: Matt Turner --- src/mesa/main/compiler.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h index 81e08a0..743841b 100644 --- a/src/mesa/main/compiler.h +++ b/src/mesa/main/compiler.h @@ -355,7 +355,7 @@ static INLINE GLuint CPU_TO_LE32(GLuint x) #ifndef M_PI -#define M_PI (3.1415926536) +#define M_PI (3.14159265358979323846) #endif #ifndef M_E -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm > 2.8
https://bugs.freedesktop.org/show_bug.cgi?id=36738 José Fonseca changed: What|Removed |Added CC||jfons...@vmware.com --- Comment #4 from José Fonseca 2011-05-04 11:29:27 PDT --- If it happens with llvm 2.9+ then it's likely a llvm bug. It could also be an interface change we don't handle properly. Iaroslav, could you please set the following env var export GALLIVM_DEBUG=tgsi,ir,asm and run openarena, both with llvm 2.8 and 2.9 and post the logs? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA -> GL_RGB
Interestingly I have just found out that this issue only happens after the machine has done a suspend/resume. On a fresh boot prior to the suspend/resume the performance is good. So I guess somehow the driver is "forgetting" that it can take a faster path that doesn't go through _mesa_texstore. Which means that it could easily be fixed in a later version. But now that I have worked around the problem I probably won't have time to delve any further. In case anyone is interested, the affected machine is the Lenovo T410. On 27 April 2011 07:39, Roland Scheidegger wrote: > Am 26.04.2011 19:35, schrieb Tristan Schmelcher: >> On 26 April 2011 08:20, Roland Scheidegger wrote: >>> Am 26.04.2011 01:15, schrieb Tristan Schmelcher: Hello, I have an OpenGL app where I'm writing video frames to textures. The video frames are semantically opaque but the alpha in the source pixels is set to 0xff, so I have been using glTexImage2D with format=GL_RGBA and internalFormat=GL_RGB to indicate that the input has a valid alpha channel but that the OpenGL implementation could discard it if it wanted to (e.g., if the hardware had native support for GL_RGB which was faster than its GL_RGBA support, or something). This has worked well for me on most systems, but today I found that it results in poor glTexSubImage2D() performance on an Intel IGDNG_M GPU (i965-based) with MESA 7.7.1 (using Ubuntu Lucid). Because internalFormat is GL_RGB instead of GL_RGBA, _mesa_texstore_argb takes a slow path by using _mesa_swizzle_ubyte_image instead of memcpy_texture. Wouldn't it make sense for _mesa_texstore_argb to use memcpy_texture in this case? Or maybe it is right to not do that since there is no way for it to know that the alpha component in the input is already set to 0xff ... but in that case shouldn't it at least take the third path--the one that uses PACK_COLOR_(0xff, ...) ? >>> >>> memcpy is pretty much out of the question - it is quite possible other >>> implementations would do this, but it's tricky. Most hw probably has >>> some bit which it can set so sampling from such a texture would always >>> return 1.0 for alpha regardless the actual values, but this is a generic >>> function shared by all drivers hence it can't assume that. And even if >>> it could, this can well break something else if you use the texture for >>> something not directly related to sampling. >>> Some PACK_COLOR_ path should work, it's probably not taken because >>> there are about 3 million different cases (based on src/dst/internal >>> format etc.) which you could code separately and this one just isn't one >>> of it for which this is done. Besides, I'm not sure how much faster this >>> is compared to _mesa_swizzle_ubyte_image (the big perf hit you take is >>> usually with the fully general path with the temp image). In any case it >>> would still be slower than memcpy. >> >> I guess that's sort of what I expected. I'll just have to use GL_RGBA >> after all then. :/ >> >> Separately, if I coded and perf-tested a PACK_COLOR_ path for >> this, is that something that people would be interested in taking into >> MESA? > > I think it would be ok though I can't speak for others. As long as the > code is simple enough. I believe the idea was to only special-case the > most common cases to keep the code sane, but supplying RGB data in RGBA > form seems like a valid case to me. > > Roland > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error building glxext.c
libGL is missing the change and version requirement bump, so you'll have to use the last glproto release until I land the Mesa fix along with a new glproto release. Sorry for the trouble; I pushed glproto yesterday assuming I'd be able to push the other bits right away too, but I'm still waiting for review. I'll revert the glproto commit today if it looks like I won't be able to do the release. Thanks, Jesse On Wed, 4 May 2011 11:01:29 -0700 Jeremy Huddleston wrote: > Well, it's not building correctly on my tinderbox which uses master glproto > and master libGL, so either libGL has bad C, or libGL is using the system's > glproto instead of the one it queries out of PKG_CONFIG_PATH. Either way, > it's a mesa bug happening on both of my linux tinderboxes (gentoo ppc64 and > ubuntu ppc): > > http://tinderbox.x.org/builds/2011-05-04-/logs/libGL/#build > http://tinderbox.x.org/builds/2011-05-04-0001/logs/libGL/#build > > On May 4, 2011, at 10:37, Jesse Barnes wrote: > > > On Wed, 04 May 2011 10:01:28 -0700 > > Ian Romanick wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> On 05/04/2011 09:40 AM, Dan McCabe wrote: > >>> Hi all, > >>> > >>> Apologies if this is a stupid n00b question, but I'm getting errors > >>> building glxext.c in mesa/mesa/src/glx. > >>> > >>> Specific error msg is: > >>>glxext.c: In function ‘__glXWireToEvent’: > >>>glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member > >>>named ‘sbc_hi’ > >>>glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member > >>>named ‘sbc_lo’ > >>> > >>> I followed the installation/build directions described here: > >>> http://wiki.x.org/wiki/ModularDevelopersGuide > >>> and I grabbed the src from git last night (early evening). > >>> > >>> Any suggestions/recommendations? > >> > >> My guess is that you need newer glproto bits. The protocol related to > >> the GLX buffer swap complete event was broken, and Jesse has been > >> working on fixing. I'd guess that you Mesa bits have the fixes applied, > >> but they need newer glproto bits to build. > > > > I think it's the reverse, I got review on the glproto bits so they're > > pushed. Still waiting on review for the Mesa, dri2proto, and X parts > > though to push the rest. > > > > So revert the top commit of glproto to get the old structure def back > > (in fact, Mesa autoconf should have complained about the glproto, but > > only if you re-run autogen.sh). > > > > -- > > Jesse Barnes, Intel Open Source Technology Center > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error building glxext.c
On Wed, 4 May 2011 10:37:03 -0700 Jesse Barnes wrote: > On Wed, 04 May 2011 10:01:28 -0700 > Ian Romanick wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 05/04/2011 09:40 AM, Dan McCabe wrote: > > > Hi all, > > > > > > Apologies if this is a stupid n00b question, but I'm getting errors > > > building glxext.c in mesa/mesa/src/glx. > > > > > > Specific error msg is: > > > glxext.c: In function ‘__glXWireToEvent’: > > > glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member > > > named ‘sbc_hi’ > > > glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member > > > named ‘sbc_lo’ > > > > > > I followed the installation/build directions described here: > > > http://wiki.x.org/wiki/ModularDevelopersGuide > > > and I grabbed the src from git last night (early evening). > > > > > > Any suggestions/recommendations? > > > > My guess is that you need newer glproto bits. The protocol related to > > the GLX buffer swap complete event was broken, and Jesse has been > > working on fixing. I'd guess that you Mesa bits have the fixes applied, > > but they need newer glproto bits to build. > > I think it's the reverse, I got review on the glproto bits so they're > pushed. Still waiting on review for the Mesa, dri2proto, and X parts > though to push the rest. > > So revert the top commit of glproto to get the old structure def back > (in fact, Mesa autoconf should have complained about the glproto, but > only if you re-run autogen.sh). Oh Mesa won't complain until I push those bits... Ian can you take a look at my mesa patch and make sure it's ok before I push? I'll do new glproto and dri2proto releases today assuming those bits are good, then push the Mesa fix; Keith will have to pull in the X fixes. Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error building glxext.c
Well, it's not building correctly on my tinderbox which uses master glproto and master libGL, so either libGL has bad C, or libGL is using the system's glproto instead of the one it queries out of PKG_CONFIG_PATH. Either way, it's a mesa bug happening on both of my linux tinderboxes (gentoo ppc64 and ubuntu ppc): http://tinderbox.x.org/builds/2011-05-04-/logs/libGL/#build http://tinderbox.x.org/builds/2011-05-04-0001/logs/libGL/#build On May 4, 2011, at 10:37, Jesse Barnes wrote: > On Wed, 04 May 2011 10:01:28 -0700 > Ian Romanick wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 05/04/2011 09:40 AM, Dan McCabe wrote: >>> Hi all, >>> >>> Apologies if this is a stupid n00b question, but I'm getting errors >>> building glxext.c in mesa/mesa/src/glx. >>> >>> Specific error msg is: >>>glxext.c: In function ‘__glXWireToEvent’: >>>glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member >>>named ‘sbc_hi’ >>>glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member >>>named ‘sbc_lo’ >>> >>> I followed the installation/build directions described here: >>> http://wiki.x.org/wiki/ModularDevelopersGuide >>> and I grabbed the src from git last night (early evening). >>> >>> Any suggestions/recommendations? >> >> My guess is that you need newer glproto bits. The protocol related to >> the GLX buffer swap complete event was broken, and Jesse has been >> working on fixing. I'd guess that you Mesa bits have the fixes applied, >> but they need newer glproto bits to build. > > I think it's the reverse, I got review on the glproto bits so they're > pushed. Still waiting on review for the Mesa, dri2proto, and X parts > though to push the rest. > > So revert the top commit of glproto to get the old structure def back > (in fact, Mesa autoconf should have complained about the glproto, but > only if you re-run autogen.sh). > > -- > Jesse Barnes, Intel Open Source Technology Center > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error building glxext.c
On Wed, 04 May 2011 10:01:28 -0700 Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/04/2011 09:40 AM, Dan McCabe wrote: > > Hi all, > > > > Apologies if this is a stupid n00b question, but I'm getting errors > > building glxext.c in mesa/mesa/src/glx. > > > > Specific error msg is: > > glxext.c: In function ‘__glXWireToEvent’: > > glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member > > named ‘sbc_hi’ > > glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member > > named ‘sbc_lo’ > > > > I followed the installation/build directions described here: > > http://wiki.x.org/wiki/ModularDevelopersGuide > > and I grabbed the src from git last night (early evening). > > > > Any suggestions/recommendations? > > My guess is that you need newer glproto bits. The protocol related to > the GLX buffer swap complete event was broken, and Jesse has been > working on fixing. I'd guess that you Mesa bits have the fixes applied, > but they need newer glproto bits to build. I think it's the reverse, I got review on the glproto bits so they're pushed. Still waiting on review for the Mesa, dri2proto, and X parts though to push the rest. So revert the top commit of glproto to get the old structure def back (in fact, Mesa autoconf should have complained about the glproto, but only if you re-run autogen.sh). -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL IR to TGSI translator
On Mon, 02 May 2011 16:44:21 -0500, Bryan Cain wrote: > On 05/02/2011 11:55 AM, Ian Romanick wrote: > > On 04/27/2011 08:23 PM, Brian Paul wrote: > > > On Tue, Apr 26, 2011 at 12:26 AM, Bryan Cain > > wrote: > > >> Hi, > > >> > > >> In the last week or so, I've been working on a direct translator from > > >> GLSL IR to TGSI that does not go through Mesa IR. Although it is still > > >> a work in progress, it is now working and very usable. So before I go > > >> on, here is a link to the branch I've pushed to GitHub: > > >> > > >> https://github.com/Plombo/mesa/tree/glsl-130 > > >> > > >> My main objective with this work is to make GLSL 1.30 support feasible > > >> on Gallium drivers. From what I understand, it would be difficult or > > >> impossible to implement integer-specific opcodes such as shifting and > > >> bit masking in Mesa IR, since it only supports floats. TGSI, on the > > >> other hand, doesn't have this problem, and already supports most or all > > >> of the functionality required by GLSL 1.30. > > > > > Unfortunately, TGSI doesn't have everything we need yet. There's > > > opcodes for binary AND, OR, XOR, etc. and a few integer operations, > > > but it's incomplete. It shouldn't be a big deal to add what's missing > > > but it'll take a little time. > > > > > I think everyone agrees that we want to eventually ditch Mesa's IR. I > > > _think_ that the only classic Mesa driver that uses Mesa IR and hasn't > > > been deprecated by a Gallium driver, or already weaned from Mesa IR is > > > swrast. How much does the i965 driver still rely on swrast for > > > fallbacks? Do the Intel people see need for a GLSL IR executor for > > > swrast? > > > > Right now i915, i965 (vertex shaders only), and r200 all use Mesa IR. > > All of the non-shader chips also use it for vertex shaders. We're in > > the process of eliminating the use of Mesa IR in i965. Mesa IR isn't a > > horrible fit for i915 or r200. Once everything else works directly from > > GLSL IR, I'll probably evolve the use of Mesa IR to better match those > > targets. It will basically become a (semi-)shared low-level IR used > > just by those drivers. > > > > I also need to finish changing the ARB_vertex_program (and friends) > > assemblers to generate GLSL IR directly. It's mostly done. There's > > really just a bunch of typing left. > > > > I don't think interpreter will go away from core Mesa any time soon. > > We'll still need it for fallbacks on a variety of chips and vertex > > shaders on non-shader GPUs. That said, I don't think it needs to > > support any of the new functionality. The only classic driver that is > > ever going to support 1.30+ is i965. When we're on 1.30 shaders and > > would need a full software fallback, I think we'll opt for > > non-conformance instead. I think there are only 3 or 4 places where we > > hit software fallbacks, and I think we can take that ding. > > > > >> The translator started as a modified version of ir_to_mesa, and that > > >> origin is still obvious from reading the code. Many parts of > > ir_to_mesa > > >> are still untouched - glsl_to_tgsi is still a long way away from > > >> eliminating all traces of Mesa IR. It also contains a significant > > >> amount of code adapted from st_mesa_to_tgsi, but modified to generate > > >> TGSI code from the glsl_to_tgsi_instruction class instead of using Mesa > > >> IR. (It actually still generates Mesa IR instructions, but that could > > >> be safely removed at some point since the generated Mesa IR > > instructions > > >> are not actually used for anything.) I'm planning to push more of the > > >> conversion to TGSI higher up in the stack in the future, although the > > >> remaining remnants of Mesa IR (such as the Mesa IR opcodes used by most > > >> of glsl_to_tgsi) aren't doing any harm. > > > > > I finally found a little time to look over your code. As you said, > > > it's basically a copy & paste of the ir_to_mesa.cpp and > > > st_mesa_to_tgsi.c code at this time. Do you plan to eliminate all > > > remnants of Mesa IR there before adding support for GLSL 1.30? One > > > easy step would be to replace use of Mesa IR opcodes with TGSI opcodes > > > and add new TGSI opcodes for integer ops. > > > > Mesa IR and TGSI are, structurally, very similar. It seems like > > starting with ir_to_mesa is the right plan. That's how the i965 > > fragment shader backend was written, and it's how we're planning to do > > the vertex shader backend. At that point, it's better to change it to > > generate TGSI instructions / opcodes instead of Mesa IR. Once you get a > > basic shader that moves a constant to the shader output working, it's > > pretty much all downhill. > > > > There's a lot more typing before you have something that compiles, but > > the overall route to the goal is much shorter. > > Right, this is exactly why I started the way I did. In fact, I've > accomplished a lot in the week since I sent my initial message, and I > recentl
Re: [Mesa-dev] Error building glxext.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/04/2011 09:40 AM, Dan McCabe wrote: > Hi all, > > Apologies if this is a stupid n00b question, but I'm getting errors > building glxext.c in mesa/mesa/src/glx. > > Specific error msg is: > glxext.c: In function ‘__glXWireToEvent’: > glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member > named ‘sbc_hi’ > glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member > named ‘sbc_lo’ > > I followed the installation/build directions described here: > http://wiki.x.org/wiki/ModularDevelopersGuide > and I grabbed the src from git last night (early evening). > > Any suggestions/recommendations? My guess is that you need newer glproto bits. The protocol related to the GLX buffer swap complete event was broken, and Jesse has been working on fixing. I'd guess that you Mesa bits have the fixes applied, but they need newer glproto bits to build. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3BhmgACgkQX1gOwKyEAw9c4ACghdjKebJ25/t0u0TZEHM/1L1F 35AAniTDElytPeC8rOWf1IBE23zcwVlx =fVkx -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Error building glxext.c
Hi all, Apologies if this is a stupid n00b question, but I'm getting errors building glxext.c in mesa/mesa/src/glx. Specific error msg is: glxext.c: In function ‘__glXWireToEvent’: glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member named ‘sbc_hi’ glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member named ‘sbc_lo’ I followed the installation/build directions described here: http://wiki.x.org/wiki/ModularDevelopersGuide and I grabbed the src from git last night (early evening). Any suggestions/recommendations? TIA cheers, danm ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Error building glxext.c
Hi all, Apologies if this is a stupid n00b question, but I'm getting errors building glxext.c in mesa/mesa/src/glx. Specific error msg is: glxext.c: In function ‘__glXWireToEvent’: glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member named ‘sbc_hi’ glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member named ‘sbc_lo’ I followed the installation/build directions described here: http://wiki.x.org/wiki/ModularDevelopersGuide and I grabbed the src from git last night (early evening). Any suggestions/recommendations? TIA cheers, danm ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: do RV6xx base updates inline with state updates.
On Wed, May 4, 2011 at 4:18 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This seems more in line with what the documentation suggests we should be
> doing. It doesn't fix the rv635 regression, though I thought it might,
> so it means I've no idea whats actually going wrong there.
Patch looks good. I'll do some more digging internally to see if I
can find any additional info.
Reviewed-by: Alex Deucher
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/winsys/r600/drm/r600_hw_context.c | 77
> +++--
> src/gallium/winsys/r600/drm/r600_priv.h | 1 +
> 2 files changed, 22 insertions(+), 56 deletions(-)
>
> diff --git a/src/gallium/winsys/r600/drm/r600_hw_context.c
> b/src/gallium/winsys/r600/drm/r600_hw_context.c
> index f639703..df12542 100644
> --- a/src/gallium/winsys/r600/drm/r600_hw_context.c
> +++ b/src/gallium/winsys/r600/drm/r600_hw_context.c
> @@ -127,10 +127,20 @@ int r600_context_add_block(struct r600_context *ctx,
> const struct r600_reg *reg,
> block->pm4_bo_index[j] = block->nbo;
> block->pm4[block->pm4_ndwords++] =
> PKT3(PKT3_NOP, 0, 0);
> block->pm4[block->pm4_ndwords++] = 0x;
> - block->reloc[block->nbo].flush_flags =
> reg[i+j].flush_flags;
> - block->reloc[block->nbo].flush_mask =
> reg[i+j].flush_mask;
> + if (reg[i+j].flags & REG_FLAG_RV6XX_SBU) {
> + block->reloc[block->nbo].flush_flags
> = 0;
> + block->reloc[block->nbo].flush_mask =
> 0;
> + } else {
> + block->reloc[block->nbo].flush_flags
> = reg[i+j].flush_flags;
> + block->reloc[block->nbo].flush_mask =
> reg[i+j].flush_mask;
> + }
> block->reloc[block->nbo].bo_pm4_index =
> block->pm4_ndwords - 1;
> }
> + if ((ctx->radeon->family > CHIP_R600) &&
> + (ctx->radeon->family < CHIP_RV770) &&
> reg[i+j].flags & REG_FLAG_RV6XX_SBU) {
> + block->pm4[block->pm4_ndwords++] =
> PKT3(PKT3_SURFACE_BASE_UPDATE, 0, 0);
> + block->pm4[block->pm4_ndwords++] =
> reg[i+j].flush_flags;
> + }
> }
> for (j = 0; j < n; j++) {
> if (reg[i+j].flush_flags) {
> @@ -197,7 +207,7 @@ static const struct r600_reg r600_context_reg_list[] = {
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028028_DB_STENCIL_CLEAR, 0, 0, 0},
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_02802C_DB_DEPTH_CLEAR, 0, 0, 0},
> {0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
> - {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028040_CB_COLOR0_BASE, REG_FLAG_NEED_BO, 0, 0},
> + {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028040_CB_COLOR0_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU,
> SURFACE_BASE_UPDATE_COLOR(0), 0},
> {0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_0280A0_CB_COLOR0_INFO, REG_FLAG_NEED_BO, 0, 0x},
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028060_CB_COLOR0_SIZE, 0, 0, 0},
> @@ -208,7 +218,7 @@ static const struct r600_reg r600_context_reg_list[] = {
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_0280C0_CB_COLOR0_TILE, REG_FLAG_NEED_BO, 0, 0},
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028100_CB_COLOR0_MASK, 0, 0, 0},
> {0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
> - {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028044_CB_COLOR1_BASE, REG_FLAG_NEED_BO, 0, 0},
> + {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028044_CB_COLOR1_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU,
> SURFACE_BASE_UPDATE_COLOR(1), 0},
> {0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_0280A4_CB_COLOR1_INFO, REG_FLAG_NEED_BO, 0, 0x},
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028064_CB_COLOR1_SIZE, 0, 0, 0},
> @@ -219,7 +229,7 @@ static const struct r600_reg r600_context_reg_list[] = {
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_0280C4_CB_COLOR1_TILE, REG_FLAG_NEED_BO, 0, 0},
> {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028104_CB_COLOR1_MASK, 0, 0, 0},
> {0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
> - {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028048_CB_COLOR2_BASE, REG_FLAG_NEED_BO, 0, 0},
> + {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
> R_028048_CB_COLOR2_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU,
> SURFACE_BASE_UPDATE_COLOR(2), 0},
> {0, 0, GROUP_FORCE_NEW_BLOCK
Re: [Mesa-dev] Name mangling in win32 build of EGL and GLESv2
- Original Message - > Hi, > > Looking at the Symbol table of a recent > (66b66295d0bc856c69fd22575580c7ecee16 ) libEGL.dll. I get the > following mangled names: > > eglBindAPI > _eglBindContext > _eglBindTexImage > eglBindTexImage > _eglBindWaylandDisplayWL@8 > _eglCheckResource > eglChooseConfig > > That is stdcall and cdecl calling convention mixed? > > and in libGLESv2.dll all functions are with stdcall conventions > > _glActiveTexture@4 > _glAttachShader@8 > _glBindAttribLocation@12 > _glBindBuffer@8 > _glBindFramebuffer@8 > > Then in libOpenVL.dll there is no mangling at all: > vgSetf > vgSetfv > vgSeti > vgSetiv > vgShear > vgTransformPath > > Is this happening by accident or on purspose? A bit of both. Mesa in someplaces uses __declspec(export) attribute, other places .DEF files, and other both. Which is why you get this mixed. IMO, we should stop using __declspec(export) attributes, and use .DEF files, which provide fine control over which symbols are public or not, and how are the names mangled. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Name mangling in win32 build of EGL and GLESv2
Hi, Looking at the Symbol table of a recent (66b66295d0bc856c69fd22575580c7ecee16 ) libEGL.dll. I get the following mangled names: eglBindAPI _eglBindContext _eglBindTexImage eglBindTexImage _eglBindWaylandDisplayWL@8 _eglCheckResource eglChooseConfig That is stdcall and cdecl calling convention mixed? and in libGLESv2.dll all functions are with stdcall conventions _glActiveTexture@4 _glAttachShader@8 _glBindAttribLocation@12 _glBindBuffer@8 _glBindFramebuffer@8 Then in libOpenVL.dll there is no mangling at all: vgSetf vgSetfv vgSeti vgSetiv vgShear vgTransformPath Is this happening by accident or on purspose? regards Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: do RV6xx base updates inline with state updates.
From: Dave Airlie
This seems more in line with what the documentation suggests we should be
doing. It doesn't fix the rv635 regression, though I thought it might,
so it means I've no idea whats actually going wrong there.
Signed-off-by: Dave Airlie
---
src/gallium/winsys/r600/drm/r600_hw_context.c | 77 +++--
src/gallium/winsys/r600/drm/r600_priv.h |1 +
2 files changed, 22 insertions(+), 56 deletions(-)
diff --git a/src/gallium/winsys/r600/drm/r600_hw_context.c
b/src/gallium/winsys/r600/drm/r600_hw_context.c
index f639703..df12542 100644
--- a/src/gallium/winsys/r600/drm/r600_hw_context.c
+++ b/src/gallium/winsys/r600/drm/r600_hw_context.c
@@ -127,10 +127,20 @@ int r600_context_add_block(struct r600_context *ctx,
const struct r600_reg *reg,
block->pm4_bo_index[j] = block->nbo;
block->pm4[block->pm4_ndwords++] =
PKT3(PKT3_NOP, 0, 0);
block->pm4[block->pm4_ndwords++] = 0x;
- block->reloc[block->nbo].flush_flags =
reg[i+j].flush_flags;
- block->reloc[block->nbo].flush_mask =
reg[i+j].flush_mask;
+ if (reg[i+j].flags & REG_FLAG_RV6XX_SBU) {
+ block->reloc[block->nbo].flush_flags =
0;
+ block->reloc[block->nbo].flush_mask = 0;
+ } else {
+ block->reloc[block->nbo].flush_flags =
reg[i+j].flush_flags;
+ block->reloc[block->nbo].flush_mask =
reg[i+j].flush_mask;
+ }
block->reloc[block->nbo].bo_pm4_index =
block->pm4_ndwords - 1;
}
+ if ((ctx->radeon->family > CHIP_R600) &&
+ (ctx->radeon->family < CHIP_RV770) &&
reg[i+j].flags & REG_FLAG_RV6XX_SBU) {
+ block->pm4[block->pm4_ndwords++] =
PKT3(PKT3_SURFACE_BASE_UPDATE, 0, 0);
+ block->pm4[block->pm4_ndwords++] =
reg[i+j].flush_flags;
+ }
}
for (j = 0; j < n; j++) {
if (reg[i+j].flush_flags) {
@@ -197,7 +207,7 @@ static const struct r600_reg r600_context_reg_list[] = {
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028028_DB_STENCIL_CLEAR, 0, 0, 0},
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_02802C_DB_DEPTH_CLEAR, 0, 0, 0},
{0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
- {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028040_CB_COLOR0_BASE, REG_FLAG_NEED_BO, 0, 0},
+ {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028040_CB_COLOR0_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU,
SURFACE_BASE_UPDATE_COLOR(0), 0},
{0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_0280A0_CB_COLOR0_INFO, REG_FLAG_NEED_BO, 0, 0x},
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028060_CB_COLOR0_SIZE, 0, 0, 0},
@@ -208,7 +218,7 @@ static const struct r600_reg r600_context_reg_list[] = {
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_0280C0_CB_COLOR0_TILE, REG_FLAG_NEED_BO, 0, 0},
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028100_CB_COLOR0_MASK, 0, 0, 0},
{0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
- {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028044_CB_COLOR1_BASE, REG_FLAG_NEED_BO, 0, 0},
+ {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028044_CB_COLOR1_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU,
SURFACE_BASE_UPDATE_COLOR(1), 0},
{0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_0280A4_CB_COLOR1_INFO, REG_FLAG_NEED_BO, 0, 0x},
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028064_CB_COLOR1_SIZE, 0, 0, 0},
@@ -219,7 +229,7 @@ static const struct r600_reg r600_context_reg_list[] = {
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_0280C4_CB_COLOR1_TILE, REG_FLAG_NEED_BO, 0, 0},
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028104_CB_COLOR1_MASK, 0, 0, 0},
{0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
- {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028048_CB_COLOR2_BASE, REG_FLAG_NEED_BO, 0, 0},
+ {PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028048_CB_COLOR2_BASE, REG_FLAG_NEED_BO|REG_FLAG_RV6XX_SBU,
SURFACE_BASE_UPDATE_COLOR(2), 0},
{0, 0, GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_0280A8_CB_COLOR2_INFO, REG_FLAG_NEED_BO, 0, 0x},
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFSET,
R_028068_CB_COLOR2_SIZE, 0, 0, 0},
@@ -230,7 +240,7 @@ static const struct r600_reg r600_context_reg_list[] = {
{PKT3_SET_CONTEXT_REG, R600_CONTEXT_REG_OFFS
