Re: [Mesa-dev] [PATCH 3/4] nine: handle D3DISSUE_END without previous D3DISSUE_BEGIN
A few Gallium queries don't need and it's invalid to call begin_query.
Those are PIPE_QUERY_GPU_FINISHED (D3DQUERYTYPE_EVENT) and
PIPE_QUERY_TIMESTAMP (D3DQUERYTYPE_TIMESTAMP).
The attached patch should fix this.
Marek
On Sat, Nov 22, 2014 at 9:48 AM, John Ettedgui wrote:
> So I tried both code you thought of.
>
> 1) Always having end_query did not seem to get a different behavior from my
> patch. (I'm sure it does somewhere but I didn't see that in my quick test).
>
> 2) Your 2nd code is more problematic (adding the begin_query as needed)
> The game completely dies/freezes, and I see this in the log:
> "r600_query.c:444:r600_begin_query: Assertion `0' failed."
> (I have a radeon card).
> The assert comes from this if statement:
> "if (!r600_query_needs_begin(rquery->type)) "
> Logically I'd say it means that we are running a query_begin when it is not
> needed.
> The query type is 8 if that helps.
>
> Now there are 2 cases:
> 1- the radeon code is correct and so we should not add that extra
> begin_query
> 2- the radeon code is incorrect and maybe adding this query_begin is right.
> The i915's code does not do anything for begin or end, so hard to compare
> there.
> The svga code switches on the query type, and will assert on the wrong
> ones. I guess it is similar to the radeon's.
> Nouveau also has switches on type, but it does not error on "wrong ones".
>
> What do you think?
>
> John
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
From 7ea5cee75dcc4435164a0f776a1243123ea90760 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?=
Date: Sun, 23 Nov 2014 11:42:42 +0100
Subject: [PATCH] st/nine: handle queries without begin
---
src/gallium/state_trackers/nine/query9.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/nine/query9.c b/src/gallium/state_trackers/nine/query9.c
index 86762d2..a7d08fa 100644
--- a/src/gallium/state_trackers/nine/query9.c
+++ b/src/gallium/state_trackers/nine/query9.c
@@ -186,10 +186,11 @@ NineQuery9_Issue( struct NineQuery9 *This,
pipe->begin_query(pipe, This->pq);
This->state = NINE_QUERY_STATE_RUNNING;
} else {
-if (This->state == NINE_QUERY_STATE_RUNNING) {
-pipe->end_query(pipe, This->pq);
-This->state = NINE_QUERY_STATE_ENDED;
- }
+if (This->state != NINE_QUERY_STATE_RUNNING && !This->instant)
+return D3D_OK;
+
+pipe->end_query(pipe, This->pq);
+This->state = NINE_QUERY_STATE_ENDED;
}
return D3D_OK;
}
--
1.8.4.msysgit.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.
https://bugs.freedesktop.org/show_bug.cgi?id=85203 alex_y...@yahoo.ca changed: What|Removed |Added CC||alex_y...@yahoo.ca --- Comment #2 from alex_y...@yahoo.ca --- Created attachment 109902 --> https://bugs.freedesktop.org/attachment.cgi?id=109902&action=edit Xorg.0.log -- 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
[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.
https://bugs.freedesktop.org/show_bug.cgi?id=85203 --- Comment #3 from alex_y...@yahoo.ca --- Created attachment 109903 --> https://bugs.freedesktop.org/attachment.cgi?id=109903&action=edit sanitized dmesg -- 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
[Mesa-dev] [PATCH] nv50/ir: set neg modifiers on min/max args
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=86618 Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp index 077eba8..3048f3d 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp @@ -924,7 +924,9 @@ CodeEmitterNV50::emitMINMAX(const Instruction *i) break; } code[1] |= i->src(0).mod.abs() << 20; + code[1] |= i->src(0).mod.neg() << 26; code[1] |= i->src(1).mod.abs() << 19; + code[1] |= i->src(1).mod.neg() << 27; } emitForm_MAD(i); } -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: implement ARB_pipeline_statistics_query
On Sun, Nov 23, 2014 at 02:12:10AM -0500, Ilia Mirkin wrote: > On Sat, Nov 22, 2014 at 6:52 PM, Ben Widawsky > wrote: > > This patch implements ARB_pipeline_statistics_query. This addition to GL > > does > > not add a new API. Instead, it adds new tokens to the existing query APIs. > > The > > work to hook up the new tokens is trivial due to it's similarity to the > > previous > > work done for the query APIs. I've implemented all the new tokens to some > > degree, but have stubbed out the untested ones at the entry point for > > Begin(). > > Doing this should allow the remainder of the code to be left in. > > > > The new tokens give GL clients a way to obtain stats about the GL pipeline. > > Generally, you get the number of things going in, invocations, and number of > > things coming out, primitives, of the various stages. There are two > > immediate > > uses for this, performance information, and debugging various types of > > misrendering. I doubt one can use these for debugging very complex > > applications, > > but for piglit tests, it should be quite useful. > > > > Tessellation shaders, and compute shaders are not addressed in this patch > > because there is no upstream implementation. I've implemented how I believe > > tessellation shader stats will work for Intel hardware (though there is a > > bit of > > ambiguity). Compute shaders are a bit more interesting though, and I don't > > yet > > know what we'll do there. > > > > For the lazy, here is a link to the relevant part of the spec: > > https://www.opengl.org/registry/specs/ARB/pipeline_statistics_query.txt > > > > I was unsure how to handle the following: > >>Dependencies on AMD_transform_feedback4 > >> > >>If AMD_transform_feedback4 is supported then > >> GEOMETRY_SHADER_PRIMITIVES_- > >>EMITTED_ARB counts primitives emitted to any of the vertex streams for > >>which STREAM_RASTERIZATION_AMD is enabled. > > > > Running the piglit tests > > http://lists.freedesktop.org/archives/piglit/2014-November/013321.html > > (http://cgit.freedesktop.org/~bwidawsk/piglit/log/?h=pipe_stats) > > yield the following results: > > > >> python2 ./piglit-run.py -t stats tests/all.py output/pipeline_stats > >> [5/5] pass: 5 Running Test(s): 5 > > > > Previously I was seeing the adjacent vertex test failing on certain Intel > > hardware. I am currently not able to reproduce this, and therefore for now, > > I'll > > assume it was some transient issue which has been fixed. > > > > Signed-off-by: Ben Widawsky > > --- > > docs/GL3.txt | 1 + > > src/mapi/glapi/gen/GL4x.xml | 14 > > src/mesa/drivers/dri/i965/gen6_queryobj.c| 116 > > +++ > > src/mesa/drivers/dri/i965/intel_extensions.c | 1 + > > src/mesa/main/config.h | 3 + > > src/mesa/main/extensions.c | 1 + > > src/mesa/main/mtypes.h | 15 > > src/mesa/main/queryobj.c | 77 ++ > > Traditionally these are split up among 3 patches, one which adds the > glapi, one which adds the core impl, and one which adds the driver > impl. It might be fine to merge the first 2 bits here. > Okay. So glapi + core which always fail followed by the implementation patch? > > 8 files changed, 228 insertions(+) > > > > diff --git a/docs/GL3.txt b/docs/GL3.txt > > index 4c07733..5f310f3 100644 > > --- a/docs/GL3.txt > > +++ b/docs/GL3.txt > > @@ -183,6 +183,7 @@ GL 4.4, GLSL 4.40: > >GL_ARB_texture_mirror_clamp_to_edge DONE (i965, nv30, > > nv50, nvc0, r300, r600, radeonsi, swrast, llvmpipe, softpipe) > >GL_ARB_texture_stencil8 not started > >GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, > > nvc0, r600, radeonsi, llvmpipe, softpipe) > > + GL_ARB_pipeline_statistics_query most of i965 is done > > I see no mention of this in the GL4.5 core spec, which likely means > it's not in the 4.4 one either. I believe GL3.txt only lists the > extensions that are required for a particular GL version. I wasn't really sure how this is done. I based it off of the blurb in the extension: The extension is written against the OpenGL 4.4 Specification, Core Profile, March 19, 2014. > > > > > GL 4.5, GLSL 4.50: > > > > diff --git a/src/mapi/glapi/gen/GL4x.xml b/src/mapi/glapi/gen/GL4x.xml > > index 848316e..4a1c172 100644 > > --- a/src/mapi/glapi/gen/GL4x.xml > > +++ b/src/mapi/glapi/gen/GL4x.xml > > @@ -44,4 +44,18 @@ > > > > > > > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > Normally these get added to a separate ARB_foo_extension.xml document... > > > + > > > > diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c > > b/src/mesa/drivers/dri/i965/gen6_queryobj.c > > index 130236e..7d03e1f 100644 > > --- a/src/mesa/drivers/dri/i965/gen6_queryobj.c > > +++
Re: [Mesa-dev] [PATCH 2/2] i965/draw state: Allow state upload to proceed when inputs are not set
On Sat, Nov 22, 2014 at 11:50:29PM -0800, Kenneth Graunke wrote: > On Saturday, November 22, 2014 11:26:39 PM Jordan Justen wrote: > > On 2014-11-22 17:33:54, Kenneth Graunke wrote: > > > On Saturday, November 22, 2014 12:02:31 PM Jordan Justen wrote: > > > > For drawing the OpenGL API should validate this before we try to upload > > > > the > > > > state. > > > > > > > > For compute, these might not be set. > > > > > > > > Signed-off-by: Jordan Justen > > > > --- > > > > src/mesa/drivers/dri/i965/brw_draw_upload.c | 4 > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c > > > > b/src/mesa/drivers/dri/i965/brw_draw_upload.c > > > > index 5a12439..28136e2 100644 > > > > --- a/src/mesa/drivers/dri/i965/brw_draw_upload.c > > > > +++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c > > > > @@ -433,6 +433,10 @@ brw_prepare_vertices(struct brw_context *brw) > > > >struct brw_vertex_element *input = &brw->vb.inputs[i]; > > > > > > > >vs_inputs &= ~BITFIELD64_BIT(i); > > > > + > > > > + if (!input->glarray) > > > > + continue; > > > > + > > > >brw->vb.enabled[brw->vb.nr_enabled++] = input; > > > > } > > > > > > Seems like you don't want to be calling this code at all when doing > > > compute. > > > > > > The draw upload code is already complicated and difficult to understand; > > > although this is a small addition, the "Inputs can be NULL?!?!?" question > > > readers might have could add to the confusion. Which is fine, if compute > > > needs to hit this code...but if it doesn't need it, skipping it altogether > > > would be clearer and simpler. > > > > > > Does compute actually want 3DSTATE_VERTEX_BUFFERS/ELEMENTS? Does it use > > > 3DPRIMITIVE? > > > > No. But, as I understanded your previous feedback, you didn't want to > > have separate state tracking for compute. > > Not necessarily. > > Jordan, could you send out a list of the command packets and state needed > to do meaningful compute work? I think that would help me understand > what's required. INTEL_DEBUG=bat would show what you're currently emitting. > > My assumption so far (which I'd like to confirm with the above list) is that > there's actually very little overlap between normal 3D drawing and general > compute work. I also know that compute shaders are kicked off via separate > glDispatchCompute and glDispatchComputeIndirect functions. I don't really > understand why we're even hitting the draw_prims driver hook. If there's > really little overlap, then creating a totally separate driver hook might > make more sense. > > Another idea I've had is that we could use a separate hardware context > (brw->hw_ctx_3d and brw->hw_ctx_compute), so both the 3D and compute pipes > could operate without interfering with one another - we wouldn't need to > consider state dirtied by one or the other. > > Again, I think seeing a list of commands would help us figure out the > best solution (hopefully both efficient and simple). > I think using a separate context is not only an excellent idea, but I suspect we'll eventually find that it's a requirement for some reason or another. My assumption echoes yours WRT to very little overlap, and I think your comments mimic some of my questions as well, so I see no need for Jordan to respond to my mail. The only modification to your request that I would ask is that Jordan send a list of where there is perceived overlap as opposed to sending the full list of state (let him do the work :P). > > Therefore, when we we upload dirty state before running compute > > operations, it is possible (and apparently likely) that the > > brw_vertices state atom will call this code. > > > > When I removed the separate compute state tracking pipeline, I found I > > only needed these two changes to be able to still use the current > > state upload with compute. > > > > -Jordan > > That's surprisingly small! > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Ben Widawsky, 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] i965: implement ARB_pipeline_statistics_query
On Sun, Nov 23, 2014 at 1:31 PM, Ben Widawsky wrote: > On Sun, Nov 23, 2014 at 02:12:10AM -0500, Ilia Mirkin wrote: >> On Sat, Nov 22, 2014 at 6:52 PM, Ben Widawsky >> wrote: >> > This patch implements ARB_pipeline_statistics_query. This addition to GL >> > does >> > not add a new API. Instead, it adds new tokens to the existing query APIs. >> > The >> > work to hook up the new tokens is trivial due to it's similarity to the >> > previous >> > work done for the query APIs. I've implemented all the new tokens to some >> > degree, but have stubbed out the untested ones at the entry point for >> > Begin(). >> > Doing this should allow the remainder of the code to be left in. >> > >> > The new tokens give GL clients a way to obtain stats about the GL pipeline. >> > Generally, you get the number of things going in, invocations, and number >> > of >> > things coming out, primitives, of the various stages. There are two >> > immediate >> > uses for this, performance information, and debugging various types of >> > misrendering. I doubt one can use these for debugging very complex >> > applications, >> > but for piglit tests, it should be quite useful. >> > >> > Tessellation shaders, and compute shaders are not addressed in this patch >> > because there is no upstream implementation. I've implemented how I believe >> > tessellation shader stats will work for Intel hardware (though there is a >> > bit of >> > ambiguity). Compute shaders are a bit more interesting though, and I don't >> > yet >> > know what we'll do there. >> > >> > For the lazy, here is a link to the relevant part of the spec: >> > https://www.opengl.org/registry/specs/ARB/pipeline_statistics_query.txt >> > >> > I was unsure how to handle the following: >> >>Dependencies on AMD_transform_feedback4 >> >> >> >>If AMD_transform_feedback4 is supported then >> >> GEOMETRY_SHADER_PRIMITIVES_- >> >>EMITTED_ARB counts primitives emitted to any of the vertex streams for >> >>which STREAM_RASTERIZATION_AMD is enabled. >> > >> > Running the piglit tests >> > http://lists.freedesktop.org/archives/piglit/2014-November/013321.html >> > (http://cgit.freedesktop.org/~bwidawsk/piglit/log/?h=pipe_stats) >> > yield the following results: >> > >> >> python2 ./piglit-run.py -t stats tests/all.py output/pipeline_stats >> >> [5/5] pass: 5 Running Test(s): 5 >> > >> > Previously I was seeing the adjacent vertex test failing on certain Intel >> > hardware. I am currently not able to reproduce this, and therefore for >> > now, I'll >> > assume it was some transient issue which has been fixed. >> > >> > Signed-off-by: Ben Widawsky >> > --- >> > docs/GL3.txt | 1 + >> > src/mapi/glapi/gen/GL4x.xml | 14 >> > src/mesa/drivers/dri/i965/gen6_queryobj.c| 116 >> > +++ >> > src/mesa/drivers/dri/i965/intel_extensions.c | 1 + >> > src/mesa/main/config.h | 3 + >> > src/mesa/main/extensions.c | 1 + >> > src/mesa/main/mtypes.h | 15 >> > src/mesa/main/queryobj.c | 77 ++ >> >> Traditionally these are split up among 3 patches, one which adds the >> glapi, one which adds the core impl, and one which adds the driver >> impl. It might be fine to merge the first 2 bits here. >> > > Okay. So glapi + core which always fail followed by the implementation patch? Which do nothing since they're not enabled by the driver. But they definitely shouldn't fail -- not all drivers will support this. > >> > 8 files changed, 228 insertions(+) >> > >> > diff --git a/docs/GL3.txt b/docs/GL3.txt >> > index 4c07733..5f310f3 100644 >> > --- a/docs/GL3.txt >> > +++ b/docs/GL3.txt >> > @@ -183,6 +183,7 @@ GL 4.4, GLSL 4.40: >> >GL_ARB_texture_mirror_clamp_to_edge DONE (i965, nv30, >> > nv50, nvc0, r300, r600, radeonsi, swrast, llvmpipe, softpipe) >> >GL_ARB_texture_stencil8 not started >> >GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, >> > nvc0, r600, radeonsi, llvmpipe, softpipe) >> > + GL_ARB_pipeline_statistics_query most of i965 is >> > done >> >> I see no mention of this in the GL4.5 core spec, which likely means >> it's not in the 4.4 one either. I believe GL3.txt only lists the >> extensions that are required for a particular GL version. > > I wasn't really sure how this is done. I based it off of the blurb in the > extension: > > The extension is written against the OpenGL 4.4 Specification, > Core Profile, March 19, 2014. Yeah, that's because extensions are written as diff's. This just tells you what it's diffing against. > >> >> > >> > GL 4.5, GLSL 4.50: >> > >> > diff --git a/src/mapi/glapi/gen/GL4x.xml b/src/mapi/glapi/gen/GL4x.xml >> > index 848316e..4a1c172 100644 >> > --- a/src/mapi/glapi/gen/GL4x.xml >> > +++ b/src/mapi/glapi/gen/GL4x.xml >> > @@ -44,4 +44,18 @@ >
Re: [Mesa-dev] [PATCH] i965: implement ARB_pipeline_statistics_query
On Sun, Nov 23, 2014 at 01:50:08PM -0500, Ilia Mirkin wrote: > On Sun, Nov 23, 2014 at 1:31 PM, Ben Widawsky wrote: > > On Sun, Nov 23, 2014 at 02:12:10AM -0500, Ilia Mirkin wrote: > >> On Sat, Nov 22, 2014 at 6:52 PM, Ben Widawsky > >> wrote: > >> > This patch implements ARB_pipeline_statistics_query. This addition to GL > >> > does > >> > not add a new API. Instead, it adds new tokens to the existing query > >> > APIs. The > >> > work to hook up the new tokens is trivial due to it's similarity to the > >> > previous > >> > work done for the query APIs. I've implemented all the new tokens to some > >> > degree, but have stubbed out the untested ones at the entry point for > >> > Begin(). > >> > Doing this should allow the remainder of the code to be left in. > >> > > >> > The new tokens give GL clients a way to obtain stats about the GL > >> > pipeline. > >> > Generally, you get the number of things going in, invocations, and > >> > number of > >> > things coming out, primitives, of the various stages. There are two > >> > immediate > >> > uses for this, performance information, and debugging various types of > >> > misrendering. I doubt one can use these for debugging very complex > >> > applications, > >> > but for piglit tests, it should be quite useful. > >> > > >> > Tessellation shaders, and compute shaders are not addressed in this patch > >> > because there is no upstream implementation. I've implemented how I > >> > believe > >> > tessellation shader stats will work for Intel hardware (though there is > >> > a bit of > >> > ambiguity). Compute shaders are a bit more interesting though, and I > >> > don't yet > >> > know what we'll do there. > >> > > >> > For the lazy, here is a link to the relevant part of the spec: > >> > https://www.opengl.org/registry/specs/ARB/pipeline_statistics_query.txt > >> > > >> > I was unsure how to handle the following: > >> >>Dependencies on AMD_transform_feedback4 > >> >> > >> >>If AMD_transform_feedback4 is supported then > >> >> GEOMETRY_SHADER_PRIMITIVES_- > >> >>EMITTED_ARB counts primitives emitted to any of the vertex streams > >> >> for > >> >>which STREAM_RASTERIZATION_AMD is enabled. > >> > > >> > Running the piglit tests > >> > http://lists.freedesktop.org/archives/piglit/2014-November/013321.html > >> > (http://cgit.freedesktop.org/~bwidawsk/piglit/log/?h=pipe_stats) > >> > yield the following results: > >> > > >> >> python2 ./piglit-run.py -t stats tests/all.py output/pipeline_stats > >> >> [5/5] pass: 5 Running Test(s): 5 > >> > > >> > Previously I was seeing the adjacent vertex test failing on certain Intel > >> > hardware. I am currently not able to reproduce this, and therefore for > >> > now, I'll > >> > assume it was some transient issue which has been fixed. > >> > > >> > Signed-off-by: Ben Widawsky > >> > --- > >> > docs/GL3.txt | 1 + > >> > src/mapi/glapi/gen/GL4x.xml | 14 > >> > src/mesa/drivers/dri/i965/gen6_queryobj.c| 116 > >> > +++ > >> > src/mesa/drivers/dri/i965/intel_extensions.c | 1 + > >> > src/mesa/main/config.h | 3 + > >> > src/mesa/main/extensions.c | 1 + > >> > src/mesa/main/mtypes.h | 15 > >> > src/mesa/main/queryobj.c | 77 ++ > >> > >> Traditionally these are split up among 3 patches, one which adds the > >> glapi, one which adds the core impl, and one which adds the driver > >> impl. It might be fine to merge the first 2 bits here. > >> > > > > Okay. So glapi + core which always fail followed by the implementation > > patch? > > Which do nothing since they're not enabled by the driver. But they > definitely shouldn't fail -- not all drivers will support this. > Sorry, I didn't mean fail in the GL API sense. I meant fail as in, return NULL in the relevant function. I think we're on the same page. This brings up a good point which I meant to highlight in the commit message and forgot. I was assuming if one of the tokens is not implemented by a driver, GL_INVALID_ENUM would be returned (as is present case for i965 with tessellation + comute). However, one could argue that this extension is all or nothing. If you support the extension, you must support all 11 tokens. Thoughts on that? > > > >> > 8 files changed, 228 insertions(+) > >> > > >> > diff --git a/docs/GL3.txt b/docs/GL3.txt > >> > index 4c07733..5f310f3 100644 > >> > --- a/docs/GL3.txt > >> > +++ b/docs/GL3.txt > >> > @@ -183,6 +183,7 @@ GL 4.4, GLSL 4.40: > >> >GL_ARB_texture_mirror_clamp_to_edge DONE (i965, > >> > nv30, nv50, nvc0, r300, r600, radeonsi, swrast, llvmpipe, softpipe) > >> >GL_ARB_texture_stencil8 not started > >> >GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, > >> > nv50, nvc0, r600, radeonsi, llvmpipe, softpipe) > >> > + GL_ARB_pipeline_stati
Re: [Mesa-dev] [PATCH] i965: implement ARB_pipeline_statistics_query
On Sun, Nov 23, 2014 at 1:55 PM, Ben Widawsky wrote: > On Sun, Nov 23, 2014 at 01:50:08PM -0500, Ilia Mirkin wrote: >> On Sun, Nov 23, 2014 at 1:31 PM, Ben Widawsky wrote: >> > On Sun, Nov 23, 2014 at 02:12:10AM -0500, Ilia Mirkin wrote: >> >> On Sat, Nov 22, 2014 at 6:52 PM, Ben Widawsky >> >> wrote: >> >> > This patch implements ARB_pipeline_statistics_query. This addition to >> >> > GL does >> >> > not add a new API. Instead, it adds new tokens to the existing query >> >> > APIs. The >> >> > work to hook up the new tokens is trivial due to it's similarity to the >> >> > previous >> >> > work done for the query APIs. I've implemented all the new tokens to >> >> > some >> >> > degree, but have stubbed out the untested ones at the entry point for >> >> > Begin(). >> >> > Doing this should allow the remainder of the code to be left in. >> >> > >> >> > The new tokens give GL clients a way to obtain stats about the GL >> >> > pipeline. >> >> > Generally, you get the number of things going in, invocations, and >> >> > number of >> >> > things coming out, primitives, of the various stages. There are two >> >> > immediate >> >> > uses for this, performance information, and debugging various types of >> >> > misrendering. I doubt one can use these for debugging very complex >> >> > applications, >> >> > but for piglit tests, it should be quite useful. >> >> > >> >> > Tessellation shaders, and compute shaders are not addressed in this >> >> > patch >> >> > because there is no upstream implementation. I've implemented how I >> >> > believe >> >> > tessellation shader stats will work for Intel hardware (though there is >> >> > a bit of >> >> > ambiguity). Compute shaders are a bit more interesting though, and I >> >> > don't yet >> >> > know what we'll do there. >> >> > >> >> > For the lazy, here is a link to the relevant part of the spec: >> >> > https://www.opengl.org/registry/specs/ARB/pipeline_statistics_query.txt >> >> > >> >> > I was unsure how to handle the following: >> >> >>Dependencies on AMD_transform_feedback4 >> >> >> >> >> >>If AMD_transform_feedback4 is supported then >> >> >> GEOMETRY_SHADER_PRIMITIVES_- >> >> >>EMITTED_ARB counts primitives emitted to any of the vertex streams >> >> >> for >> >> >>which STREAM_RASTERIZATION_AMD is enabled. >> >> > >> >> > Running the piglit tests >> >> > http://lists.freedesktop.org/archives/piglit/2014-November/013321.html >> >> > (http://cgit.freedesktop.org/~bwidawsk/piglit/log/?h=pipe_stats) >> >> > yield the following results: >> >> > >> >> >> python2 ./piglit-run.py -t stats tests/all.py output/pipeline_stats >> >> >> [5/5] pass: 5 Running Test(s): 5 >> >> > >> >> > Previously I was seeing the adjacent vertex test failing on certain >> >> > Intel >> >> > hardware. I am currently not able to reproduce this, and therefore for >> >> > now, I'll >> >> > assume it was some transient issue which has been fixed. >> >> > >> >> > Signed-off-by: Ben Widawsky >> >> > --- >> >> > docs/GL3.txt | 1 + >> >> > src/mapi/glapi/gen/GL4x.xml | 14 >> >> > src/mesa/drivers/dri/i965/gen6_queryobj.c| 116 >> >> > +++ >> >> > src/mesa/drivers/dri/i965/intel_extensions.c | 1 + >> >> > src/mesa/main/config.h | 3 + >> >> > src/mesa/main/extensions.c | 1 + >> >> > src/mesa/main/mtypes.h | 15 >> >> > src/mesa/main/queryobj.c | 77 ++ >> >> >> >> Traditionally these are split up among 3 patches, one which adds the >> >> glapi, one which adds the core impl, and one which adds the driver >> >> impl. It might be fine to merge the first 2 bits here. >> >> >> > >> > Okay. So glapi + core which always fail followed by the implementation >> > patch? >> >> Which do nothing since they're not enabled by the driver. But they >> definitely shouldn't fail -- not all drivers will support this. >> > > Sorry, I didn't mean fail in the GL API sense. I meant fail as in, return NULL > in the relevant function. I think we're on the same page. > > This brings up a good point which I meant to highlight in the commit message > and > forgot. I was assuming if one of the tokens is not implemented by a driver, > GL_INVALID_ENUM would be returned (as is present case for i965 with > tessellation > + comute). However, one could argue that this extension is all or nothing. If > you support the extension, you must support all 11 tokens. Thoughts on that? > >> > >> >> > 8 files changed, 228 insertions(+) >> >> > >> >> > diff --git a/docs/GL3.txt b/docs/GL3.txt >> >> > index 4c07733..5f310f3 100644 >> >> > --- a/docs/GL3.txt >> >> > +++ b/docs/GL3.txt >> >> > @@ -183,6 +183,7 @@ GL 4.4, GLSL 4.40: >> >> >GL_ARB_texture_mirror_clamp_to_edge DONE (i965, >> >> > nv30, nv50, nvc0, r300, r600, radeonsi, swrast, llvmpipe, softpipe) >> >> >GL_ARB_texture_stencil8
Re: [Mesa-dev] [PATCH 3/4] r600/radeonsi: implement new float comparison instructions
Hi Roland,
What's the reason for not using an ordered comparison for SNE?
Marek
On Tue, Aug 13, 2013 at 7:04 PM, wrote:
> From: Roland Scheidegger
>
> Also use ordered comparisons for old cmp instructions. Untested.
> ---
> src/gallium/drivers/r600/r600_shader.c | 18 ---
> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 49
>
> 2 files changed, 48 insertions(+), 19 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_shader.c
> b/src/gallium/drivers/r600/r600_shader.c
> index 37298cc..fb766c4 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -5743,11 +5743,10 @@ static struct r600_shader_tgsi_instruction
> r600_shader_tgsi_instruction[] = {
> {105, 0, ALU_OP0_NOP, tgsi_unsupported},
> {106, 0, ALU_OP0_NOP, tgsi_unsupported},
> {TGSI_OPCODE_NOP, 0, ALU_OP0_NOP, tgsi_unsupported},
> - /* gap */
> - {108, 0, ALU_OP0_NOP, tgsi_unsupported},
> - {109, 0, ALU_OP0_NOP, tgsi_unsupported},
> - {110, 0, ALU_OP0_NOP, tgsi_unsupported},
> - {111, 0, ALU_OP0_NOP, tgsi_unsupported},
> + {TGSI_OPCODE_FSEQ, 0, ALU_OP2_SETE_DX10, tgsi_op2},
> + {TGSI_OPCODE_FSGE, 0, ALU_OP2_SETGE_DX10, tgsi_op2},
> + {TGSI_OPCODE_FSLT, 0, ALU_OP2_SETGT_DX10, tgsi_op2_swap},
> + {TGSI_OPCODE_FSNE, 0, ALU_OP2_SETNE_DX10, tgsi_op2_swap},
> {TGSI_OPCODE_NRM4, 0, ALU_OP0_NOP, tgsi_unsupported},
> {TGSI_OPCODE_CALLNZ,0, ALU_OP0_NOP, tgsi_unsupported},
> /* gap */
> @@ -5936,11 +5935,10 @@ static struct r600_shader_tgsi_instruction
> eg_shader_tgsi_instruction[] = {
> {105, 0, ALU_OP0_NOP, tgsi_unsupported},
> {106, 0, ALU_OP0_NOP, tgsi_unsupported},
> {TGSI_OPCODE_NOP, 0, ALU_OP0_NOP, tgsi_unsupported},
> - /* gap */
> - {108, 0, ALU_OP0_NOP, tgsi_unsupported},
> - {109, 0, ALU_OP0_NOP, tgsi_unsupported},
> - {110, 0, ALU_OP0_NOP, tgsi_unsupported},
> - {111, 0, ALU_OP0_NOP, tgsi_unsupported},
> + {TGSI_OPCODE_FSEQ, 0, ALU_OP2_SETE_DX10, tgsi_op2},
> + {TGSI_OPCODE_FSGE, 0, ALU_OP2_SETGE_DX10, tgsi_op2},
> + {TGSI_OPCODE_FSLT, 0, ALU_OP2_SETGT_DX10, tgsi_op2_swap},
> + {TGSI_OPCODE_FSNE, 0, ALU_OP2_SETNE_DX10, tgsi_op2_swap},
> {TGSI_OPCODE_NRM4, 0, ALU_OP0_NOP, tgsi_unsupported},
> {TGSI_OPCODE_CALLNZ,0, ALU_OP0_NOP, tgsi_unsupported},
> /* gap */
> diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> index 7a47746..8ff9abd 100644
> --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> @@ -850,18 +850,16 @@ static void emit_cmp(
> LLVMRealPredicate pred;
> LLVMValueRef cond;
>
> - /* XXX I'm not sure whether to do unordered or ordered comparisons,
> -* but llvmpipe uses unordered comparisons, so for consistency we use
> -* unordered. (The authors of llvmpipe aren't sure about using
> -* unordered vs ordered comparisons either.
> + /* Use ordered for everything but NE (which is usual for
> +* float comparisons)
> */
> switch (emit_data->inst->Instruction.Opcode) {
> - case TGSI_OPCODE_SGE: pred = LLVMRealUGE; break;
> - case TGSI_OPCODE_SEQ: pred = LLVMRealUEQ; break;
> - case TGSI_OPCODE_SLE: pred = LLVMRealULE; break;
> - case TGSI_OPCODE_SLT: pred = LLVMRealULT; break;
> + case TGSI_OPCODE_SGE: pred = LLVMRealOGE; break;
> + case TGSI_OPCODE_SEQ: pred = LLVMRealOEQ; break;
> + case TGSI_OPCODE_SLE: pred = LLVMRealOLE; break;
> + case TGSI_OPCODE_SLT: pred = LLVMRealOLT; break;
> case TGSI_OPCODE_SNE: pred = LLVMRealUNE; break;
> - case TGSI_OPCODE_SGT: pred = LLVMRealUGT; break;
> + case TGSI_OPCODE_SGT: pred = LLVMRealOGT; break;
> default: assert(!"unknown instruction"); pred = 0; break;
> }
>
> @@ -872,6 +870,35 @@ static void emit_cmp(
> cond, bld_base->base.one, bld_base->base.zero, "");
> }
>
> +static void emit_fcmp(
> + const struct lp_build_tgsi_action *action,
> + struct lp_build_tgsi_context * bld_base,
> + struct lp_build_emit_data * emit_data)
> +{
> + LLVMBuilderRef builder = bld_base->base.gallivm->builder;
> + LLVMContextRef context = bld_base->base.gallivm->context;
> + LLVMRealPredicate pred;
> +
> + /* Use ordered for everything but NE (which is usual for
> +* float comparisons)
> +*/
> + switch (emit_data->inst->Instruction.Opc
[Mesa-dev] [PATCH 05/11] st/nine: return GetAvailableTextureMem in bytes as expected (v2)
PIPE_CAP_VIDEO_MEMORY returns the amount of video memory in megabytes,
so need to converted it to bytes.
Fixed Warframe memory detection.
v2: also prepare for cards with more than 4GB memory
Cc: "10.4"
Tested-by: Yaroslav Andrusyak
Reviewed-by: Axel Davy
Signed-off-by: David Heidelberg
---
src/gallium/state_trackers/nine/device9.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index 66d5e66..d48f47d 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -423,7 +423,11 @@ NineDevice9_TestCooperativeLevel( struct NineDevice9 *This
)
UINT WINAPI
NineDevice9_GetAvailableTextureMem( struct NineDevice9 *This )
{
-return This->screen->get_param(This->screen, PIPE_CAP_VIDEO_MEMORY);
+ const unsigned mem = This->screen->get_param(This->screen,
PIPE_CAP_VIDEO_MEMORY);
+ if (mem < 4096)
+ return mem << 20;
+ else
+ return UINT_MAX;
}
HRESULT WINAPI
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/11] st/nine: propertly declare constants
From: Axel Davy Fixes "Error : CONST[20]: Undeclared source register" when running dx9_alpha_blending_material. Also artifacts on ilo. Cc: "10.4" Tested-by: David Heidelberg Signed-off-by: Axel Davy --- src/gallium/state_trackers/nine/nine_ff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/state_trackers/nine/nine_ff.c b/src/gallium/state_trackers/nine/nine_ff.c index 6890933..f2dbae4 100644 --- a/src/gallium/state_trackers/nine/nine_ff.c +++ b/src/gallium/state_trackers/nine/nine_ff.c @@ -189,10 +189,10 @@ static void nine_ureg_tgsi_dump(struct ureg_program *ureg, boolean override) /* AL should contain base address of lights table. */ #define LIGHT_CONST(i)\ -ureg_src_indirect(ureg_src_register(TGSI_FILE_CONSTANT, (i)), _X(AL)) +ureg_src_indirect(ureg_DECL_constant(ureg, i), _X(AL)) #define MATERIAL_CONST(i) \ -ureg_src_register(TGSI_FILE_CONSTANT, 19 + (i)) +ureg_DECL_constant(ureg, 19 + (i)) #define MISC_CONST(i) \ ureg_src_register(TGSI_FILE_CONSTANT, (i)) -- 2.1.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/11] st/nine: Add pool check to SetTexture (v2)
From: Axel Davy
D3DPOOL_SCRATCH is disallowed according to spec.
D3DPOOL_SYSTEMMEM should be allowed but we don't handle it right for now.
v2: Fixes segfault in SetTexture when unsetting the texture
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index e083536..66d5e66 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -2199,6 +2199,7 @@ NineDevice9_SetTexture( struct NineDevice9 *This,
IDirect3DBaseTexture9 *pTexture )
{
struct nine_state *state = This->update;
+struct NineBaseTexture9 *tex = NineBaseTexture9(pTexture);
DBG("This=%p Stage=%u pTexture=%p\n", This, Stage, pTexture);
@@ -2206,12 +2207,19 @@ NineDevice9_SetTexture( struct NineDevice9 *This,
Stage == D3DDMAPSAMPLER ||
(Stage >= D3DVERTEXTEXTURESAMPLER0 &&
Stage <= D3DVERTEXTEXTURESAMPLER3), D3DERR_INVALIDCALL);
+user_assert(!tex || tex->base.pool != D3DPOOL_SCRATCH, D3DERR_INVALIDCALL);
+
+if (unlikely(tex && tex->base.pool == D3DPOOL_SYSTEMMEM)) {
+/* TODO: Currently not implemented. Better return error
+ * with message telling what's wrong */
+ERR("This=%p D3DPOOL_SYSTEMMEM not implemented for SetTexture\n",
This);
+user_assert(tex->base.pool != D3DPOOL_SYSTEMMEM, D3DERR_INVALIDCALL);
+}
if (Stage >= D3DDMAPSAMPLER)
Stage = Stage - D3DDMAPSAMPLER + NINE_MAX_SAMPLERS_PS;
if (!This->is_recording) {
-struct NineBaseTexture9 *tex = NineBaseTexture9(pTexture);
struct NineBaseTexture9 *old = state->texture[Stage];
if (old == tex)
return D3D_OK;
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nine: the .pc file should not follow mesa version
Reviewed-by: David Heidelberg
On 11/22/2014 05:23 AM, Emil Velikov wrote:
The version provided by it should be the same as the one
provided/handled by the module. Add the missing tiny version.
Cc:
Signed-off-by: Emil Velikov
---
configure.ac| 2 ++
src/gallium/targets/d3dadapter9/Makefile.am | 2 +-
src/gallium/targets/d3dadapter9/d3d.pc.in | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 33cbf22..f99ea3d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2085,6 +2085,8 @@ AM_CONDITIONAL(HAVE_SPARC_ASM, test "x$asm_arch" = xsparc)
AC_SUBST([NINE_MAJOR], 1)
AC_SUBST([NINE_MINOR], 0)
+AC_SUBST([NINE_TINY], 0)
+AC_SUBST([NINE_VERSION], "$NINE_MAJOR.$NINE_MINOR.$NINE_TINY")
AC_SUBST([VDPAU_MAJOR], 1)
AC_SUBST([VDPAU_MINOR], 0)
diff --git a/src/gallium/targets/d3dadapter9/Makefile.am
b/src/gallium/targets/d3dadapter9/Makefile.am
index 6231236..dc97931 100644
--- a/src/gallium/targets/d3dadapter9/Makefile.am
+++ b/src/gallium/targets/d3dadapter9/Makefile.am
@@ -62,7 +62,7 @@ d3dadapter9_la_LDFLAGS = \
-shrext .so \
-module \
-no-undefined \
- -version-number $(NINE_MAJOR):$(NINE_MINOR) \
+ -version-number $(NINE_MAJOR):$(NINE_MINOR):$(NINE_TINY) \
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)
diff --git a/src/gallium/targets/d3dadapter9/d3d.pc.in b/src/gallium/targets/d3dadapter9/d3d.pc.in
index 9a18a5c..d34b2a7 100644
--- a/src/gallium/targets/d3dadapter9/d3d.pc.in
+++ b/src/gallium/targets/d3dadapter9/d3d.pc.in
@@ -6,6 +6,6 @@ moduledir=@D3D_DRIVER_INSTALL_DIR@
Name: d3d
Description: Native D3D driver modules
-Version: @VERSION@
+Version: @NINE_VERSION@
Requires.private: @DRI_PC_REQ_PRIV@
Cflags: -I${includedir}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: do all CUBE ALU operations before gradient texture operations (v2)
From: Dave Airlie
This moves all the CUBE section above the gradients section,
it also fixes a bug with gradient handling in the bytecode handling
where the gradient dst register should be ignored but isn't
causing the subsequent sample_g to fail into a second tex clause.
v2: avoid changes to bytecode by using spare temps
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 136 +
1 file changed, 72 insertions(+), 64 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 41caac3..e7b39be 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -5095,6 +5095,14 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
inst->Instruction.Opcode == TGSI_OPCODE_TG4)
sampler_src_reg = 2;
+ /* TGSI moves the sampler to src reg 3 for TXD */
+ if (inst->Instruction.Opcode == TGSI_OPCODE_TXD)
+ sampler_src_reg = 3;
+
+ sampler_index_mode = inst->Src[sampler_src_reg].Indirect.Index == 2 ? 2
: 0; // CF_INDEX_1 : CF_INDEX_NONE
+ if (sampler_index_mode)
+ ctx->shader->uses_index_registers = true;
+
src_gpr = tgsi_tex_get_src_gpr(ctx, 0);
if (inst->Texture.Texture == TGSI_TEXTURE_BUFFER) {
@@ -5109,67 +5117,7 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
}
}
- if (inst->Instruction.Opcode == TGSI_OPCODE_TXD) {
- int temp_h, temp_v;
- /* TGSI moves the sampler to src reg 3 for TXD */
- sampler_src_reg = 3;
-
- sampler_index_mode = inst->Src[sampler_src_reg].Indirect.Index
== 2 ? 2 : 0; // CF_INDEX_1 : CF_INDEX_NONE
-
- src_loaded = TRUE;
- for (i = 0; i < 3; i++) {
- int treg = r600_get_temp(ctx);
-
- if (i == 0)
- src_gpr = treg;
- else if (i == 1)
- temp_h = treg;
- else
- temp_v = treg;
-
- for (j = 0; j < 4; j++) {
- memset(&alu, 0, sizeof(struct
r600_bytecode_alu));
- alu.op = ALU_OP1_MOV;
-r600_bytecode_src(&alu.src[0], &ctx->src[i],
j);
-alu.dst.sel = treg;
-alu.dst.chan = j;
-if (j == 3)
- alu.last = 1;
-alu.dst.write = 1;
-r = r600_bytecode_add_alu(ctx->bc, &alu);
-if (r)
-return r;
- }
- }
- for (i = 1; i < 3; i++) {
- /* set gradients h/v */
- memset(&tex, 0, sizeof(struct r600_bytecode_tex));
- tex.op = (i == 1) ? FETCH_OP_SET_GRADIENTS_H :
- FETCH_OP_SET_GRADIENTS_V;
- tex.sampler_id = tgsi_tex_get_src_gpr(ctx,
sampler_src_reg);
- tex.sampler_index_mode = sampler_index_mode;
- tex.resource_id = tex.sampler_id +
R600_MAX_CONST_BUFFERS;
- tex.resource_index_mode = sampler_index_mode;
-
- tex.src_gpr = (i == 1) ? temp_h : temp_v;
- tex.src_sel_x = 0;
- tex.src_sel_y = 1;
- tex.src_sel_z = 2;
- tex.src_sel_w = 3;
-
- tex.dst_gpr = ctx->temp_reg; /* just to avoid confusing
the asm scheduler */
- tex.dst_sel_x = tex.dst_sel_y = tex.dst_sel_z =
tex.dst_sel_w = 7;
- if (inst->Texture.Texture != TGSI_TEXTURE_RECT) {
- tex.coord_type_x = 1;
- tex.coord_type_y = 1;
- tex.coord_type_z = 1;
- tex.coord_type_w = 1;
- }
- r = r600_bytecode_add_tex(ctx->bc, &tex);
- if (r)
- return r;
- }
- } else if (inst->Instruction.Opcode == TGSI_OPCODE_TXP) {
+ if (inst->Instruction.Opcode == TGSI_OPCODE_TXP) {
int out_chan;
/* Add perspective divide */
if (ctx->bc->chip_class == CAYMAN) {
@@ -5233,9 +5181,6 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
src_gpr = ctx->temp_reg;
}
- sampler_index_mode = inst->Src[sampler_src_reg].Indirect.Index == 2 ? 2
: 0; // CF_INDEX_1 : CF_INDEX_NONE
- if (sampler_index_mode)
- ctx->shader->uses_index_registers = true;
if ((inst
Re: [Mesa-dev] [PATCH] r600: fix texture gradients instruction emission (v2)
On Tue, 18 Nov 2014 23:53:23 +0100, Dave Airlie wrote:
From: Dave Airlie
The piglit tests were failing, and it appeared to be SB
optimising out things, but Glenn pointed out the gradients
are meant to be clause local, so we should emit the texture
instructions in the same clause. This moves things around
to always copy to a temp and then emit the texture clauses
for H/V.
v2: Glenn pointed out we could get another ALU fetch in
the wrong place, so load the src gpr earlier as well.
Fixes at least:
./bin/tex-miplevel-selection textureGrad 2D
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 59
++
1 file changed, 31 insertions(+), 28 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 76daf2c..41caac3 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -5110,11 +5110,37 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
}
if (inst->Instruction.Opcode == TGSI_OPCODE_TXD) {
+ int temp_h, temp_v;
/* TGSI moves the sampler to src reg 3 for TXD */
sampler_src_reg = 3;
sampler_index_mode = inst->Src[sampler_src_reg].Indirect.Index == 2 ?
2 : 0; // CF_INDEX_1 : CF_INDEX_NONE
+ src_loaded = TRUE;
+ for (i = 0; i < 3; i++) {
+ int treg = r600_get_temp(ctx);
+
+ if (i == 0)
+ src_gpr = treg;
+ else if (i == 1)
+ temp_h = treg;
+ else
+ temp_v = treg;
+
+ for (j = 0; j < 4; j++) {
+ memset(&alu, 0, sizeof(struct
r600_bytecode_alu));
+ alu.op = ALU_OP1_MOV;
+r600_bytecode_src(&alu.src[0],
&ctx->src[i], j);
+alu.dst.sel = treg;
+alu.dst.chan = j;
+if (j == 3)
+ alu.last = 1;
+alu.dst.write = 1;
+r = r600_bytecode_add_alu(ctx->bc,
&alu);
+if (r)
+return r;
+ }
+ }
for (i = 1; i < 3; i++) {
/* set gradients h/v */
memset(&tex, 0, sizeof(struct r600_bytecode_tex));
@@ -5125,35 +5151,12 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
tex.resource_id = tex.sampler_id +
R600_MAX_CONST_BUFFERS;
tex.resource_index_mode = sampler_index_mode;
- if (tgsi_tex_src_requires_loading(ctx, i)) {
- tex.src_gpr = r600_get_temp(ctx);
- tex.src_sel_x = 0;
- tex.src_sel_y = 1;
- tex.src_sel_z = 2;
- tex.src_sel_w = 3;
+ tex.src_gpr = (i == 1) ? temp_h : temp_v;
+ tex.src_sel_x = 0;
+ tex.src_sel_y = 1;
+ tex.src_sel_z = 2;
+ tex.src_sel_w = 3;
- for (j = 0; j < 4; j++) {
- memset(&alu, 0, sizeof(struct
r600_bytecode_alu));
- alu.op = ALU_OP1_MOV;
-r600_bytecode_src(&alu.src[0],
&ctx->src[i], j);
-alu.dst.sel = tex.src_gpr;
-alu.dst.chan = j;
-if (j == 3)
-alu.last = 1;
-alu.dst.write = 1;
-r =
r600_bytecode_add_alu(ctx->bc, &alu);
-if (r)
-return r;
- }
-
- } else {
- tex.src_gpr = tgsi_tex_get_src_gpr(ctx, i);
- tex.src_sel_x = ctx->src[i].swizzle[0];
- tex.src_sel_y = ctx->src[i].swizzle[1];
- tex.src_sel_z = ctx->src[i].swizzle[2];
- tex.src_sel_w = ctx->src[i].swizzle[3];
- tex.src_rel = ctx->src[i].rel;
- }
tex.dst_gpr = ctx->temp_reg; /* just to avoid confusing the asm
scheduler */
tex.dst_sel_x = tex.dst_sel_y = tex.dst_sel_z =
tex.dst_sel_w = 7;
if (inst->Texture.Texture != TGSI_TEXTURE_RECT) {
Reviewed-
Re: [Mesa-dev] [PATCH 3/4] r600/radeonsi: implement new float comparison instructions
Am 23.11.2014 um 22:34 schrieb Marek Olšák:
> Hi Roland,
>
> What's the reason for not using an ordered comparison for SNE?
Well, I guess for consistency with the new Fxxx versions (essentially
dx10). All ordered except not equal which is unordered (I have no idea
if that's what the r600 does with with the non-dx10 version of this opcode).
I have to say though for the old opcodes this behavior is probably not
really required. GL most likely allows you to do whatever you want
anyway. These should be used mostly for non integer capable hardware and
not everybody might do the same (d3d9 and hardware didn't really support
NaNs so it didn't matter). Behavior with NaNs in general (or Infs for
that matter) is not really that well defined in gallium/tgsi, you can't
actually distinguish a shader which needs to honor dx10 (or opencl or
whatever) rules for accuracy / non-normal number treatment from one
which does not have to (at least older GL versions allowed just about
everything wrt float math).
Roland
>
> Marek
>
> On Tue, Aug 13, 2013 at 7:04 PM, wrote:
>> From: Roland Scheidegger
>>
>> Also use ordered comparisons for old cmp instructions. Untested.
>> ---
>> src/gallium/drivers/r600/r600_shader.c | 18 ---
>> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 49
>>
>> 2 files changed, 48 insertions(+), 19 deletions(-)
>>
>> diff --git a/src/gallium/drivers/r600/r600_shader.c
>> b/src/gallium/drivers/r600/r600_shader.c
>> index 37298cc..fb766c4 100644
>> --- a/src/gallium/drivers/r600/r600_shader.c
>> +++ b/src/gallium/drivers/r600/r600_shader.c
>> @@ -5743,11 +5743,10 @@ static struct r600_shader_tgsi_instruction
>> r600_shader_tgsi_instruction[] = {
>> {105, 0, ALU_OP0_NOP, tgsi_unsupported},
>> {106, 0, ALU_OP0_NOP, tgsi_unsupported},
>> {TGSI_OPCODE_NOP, 0, ALU_OP0_NOP, tgsi_unsupported},
>> - /* gap */
>> - {108, 0, ALU_OP0_NOP, tgsi_unsupported},
>> - {109, 0, ALU_OP0_NOP, tgsi_unsupported},
>> - {110, 0, ALU_OP0_NOP, tgsi_unsupported},
>> - {111, 0, ALU_OP0_NOP, tgsi_unsupported},
>> + {TGSI_OPCODE_FSEQ, 0, ALU_OP2_SETE_DX10, tgsi_op2},
>> + {TGSI_OPCODE_FSGE, 0, ALU_OP2_SETGE_DX10, tgsi_op2},
>> + {TGSI_OPCODE_FSLT, 0, ALU_OP2_SETGT_DX10, tgsi_op2_swap},
>> + {TGSI_OPCODE_FSNE, 0, ALU_OP2_SETNE_DX10, tgsi_op2_swap},
>> {TGSI_OPCODE_NRM4, 0, ALU_OP0_NOP, tgsi_unsupported},
>> {TGSI_OPCODE_CALLNZ,0, ALU_OP0_NOP, tgsi_unsupported},
>> /* gap */
>> @@ -5936,11 +5935,10 @@ static struct r600_shader_tgsi_instruction
>> eg_shader_tgsi_instruction[] = {
>> {105, 0, ALU_OP0_NOP, tgsi_unsupported},
>> {106, 0, ALU_OP0_NOP, tgsi_unsupported},
>> {TGSI_OPCODE_NOP, 0, ALU_OP0_NOP, tgsi_unsupported},
>> - /* gap */
>> - {108, 0, ALU_OP0_NOP, tgsi_unsupported},
>> - {109, 0, ALU_OP0_NOP, tgsi_unsupported},
>> - {110, 0, ALU_OP0_NOP, tgsi_unsupported},
>> - {111, 0, ALU_OP0_NOP, tgsi_unsupported},
>> + {TGSI_OPCODE_FSEQ, 0, ALU_OP2_SETE_DX10, tgsi_op2},
>> + {TGSI_OPCODE_FSGE, 0, ALU_OP2_SETGE_DX10, tgsi_op2},
>> + {TGSI_OPCODE_FSLT, 0, ALU_OP2_SETGT_DX10, tgsi_op2_swap},
>> + {TGSI_OPCODE_FSNE, 0, ALU_OP2_SETNE_DX10, tgsi_op2_swap},
>> {TGSI_OPCODE_NRM4, 0, ALU_OP0_NOP, tgsi_unsupported},
>> {TGSI_OPCODE_CALLNZ,0, ALU_OP0_NOP, tgsi_unsupported},
>> /* gap */
>> diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
>> b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
>> index 7a47746..8ff9abd 100644
>> --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
>> +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
>> @@ -850,18 +850,16 @@ static void emit_cmp(
>> LLVMRealPredicate pred;
>> LLVMValueRef cond;
>>
>> - /* XXX I'm not sure whether to do unordered or ordered comparisons,
>> -* but llvmpipe uses unordered comparisons, so for consistency we use
>> -* unordered. (The authors of llvmpipe aren't sure about using
>> -* unordered vs ordered comparisons either.
>> + /* Use ordered for everything but NE (which is usual for
>> +* float comparisons)
>> */
>> switch (emit_data->inst->Instruction.Opcode) {
>> - case TGSI_OPCODE_SGE: pred = LLVMRealUGE; break;
>> - case TGSI_OPCODE_SEQ: pred = LLVMRealUEQ; break;
>> - case TGSI_OPCODE_SLE: pred = LLVMRealULE; break;
>> - case TGSI_OPCODE_SLT: pred = LLVMRealULT; break;
>> + case TGSI_OPCODE_SGE: pred = LLVMRealOGE; break;
>> + case TGSI_OPCODE_SEQ: pred = LLVMRealOEQ; break;
>> + case TGSI_OPCO
Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] glsl: Generate unique names for each const array lowered to uniforms
Hi Chris,
These two patches haven't landed in master. Did they fall through the
cracks or you're planning to do more work on them ? Afaics Ken is happy
with their current state.
Thanks
Emil
On 18/11/14 08:15, Chris Forbes wrote:
> Uniform names (even for hidden uniforms) are required to be unique; some
> parts of the compiler assume they can be looked up by name.
>
> Fixes the piglit test: tests/spec/glsl-1.20/linker/array-initializers-1
>
> Signed-off-by: Chris Forbes
> Cc: "10.4"
> ---
> src/glsl/lower_const_arrays_to_uniforms.cpp | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/glsl/lower_const_arrays_to_uniforms.cpp
> b/src/glsl/lower_const_arrays_to_uniforms.cpp
> index b3c0ee2..700e903 100644
> --- a/src/glsl/lower_const_arrays_to_uniforms.cpp
> +++ b/src/glsl/lower_const_arrays_to_uniforms.cpp
> @@ -49,6 +49,7 @@ public:
> {
>instructions = insts;
>progress = false;
> + index = 0;
> }
>
> bool run()
> @@ -62,6 +63,7 @@ public:
> private:
> exec_list *instructions;
> bool progress;
> + unsigned index;
> };
>
> void
> @@ -76,8 +78,10 @@ lower_const_array_visitor::handle_rvalue(ir_rvalue
> **rvalue)
>
> void *mem_ctx = ralloc_parent(con);
>
> + char *uniform_name = ralloc_asprintf(mem_ctx, "constarray__%d", index++);
> +
> ir_variable *uni =
> - new(mem_ctx) ir_variable(con->type, "constarray", ir_var_uniform);
> + new(mem_ctx) ir_variable(con->type, uniform_name, ir_var_uniform);
> uni->constant_initializer = con;
> uni->constant_value = con;
> uni->data.has_initializer = true;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: add template mesa 10.5.0 relnotes page
Signed-off-by: Emil Velikov --- Perhaps I'll add this to the list of things for the branchpoint :) Note that the version includes the forever missing trailing 0. -Emil docs/relnotes/10.5.0.html | 61 +++ 1 file changed, 61 insertions(+) create mode 100644 docs/relnotes/10.5.0.html diff --git a/docs/relnotes/10.5.0.html b/docs/relnotes/10.5.0.html new file mode 100644 index 000..84bfcdb --- /dev/null +++ b/docs/relnotes/10.5.0.html @@ -0,0 +1,61 @@ +http://www.w3.org/TR/html4/loose.dtd";> + + + + Mesa Release Notes + + + + + + The Mesa 3D Graphics Library + + + + + +Mesa 10.5.0 Release Notes / TBD + + +Mesa 10.5.0 is a new development release. +People who are concerned with stability and reliability should stick +with a previous release or wait for Mesa 10.5.1. + + +Mesa 10.5.0 implements the OpenGL 3.3 API, but the version reported by +glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) / +glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used. +Some drivers don't support all the features required in OpenGL 3.3. OpenGL +3.3 is only available if requested at context creation +because compatibility contexts are not supported. + + + +MD5 checksums + +TBD. + + + +New features + + +Note: some of the new features are only available with certain drivers. + + + + + + +Bug fixes + +TBD. + +Changes + + + + + + + -- 2.1.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] glsl: Generate unique names for each const array lowered to uniforms
Just fallen through the cracks. I'll land them after work (a few hours).
On Mon, Nov 24, 2014 at 2:01 PM, Emil Velikov wrote:
> Hi Chris,
>
> These two patches haven't landed in master. Did they fall through the
> cracks or you're planning to do more work on them ? Afaics Ken is happy
> with their current state.
>
> Thanks
> Emil
>
> On 18/11/14 08:15, Chris Forbes wrote:
>> Uniform names (even for hidden uniforms) are required to be unique; some
>> parts of the compiler assume they can be looked up by name.
>>
>> Fixes the piglit test: tests/spec/glsl-1.20/linker/array-initializers-1
>>
>> Signed-off-by: Chris Forbes
>> Cc: "10.4"
>> ---
>> src/glsl/lower_const_arrays_to_uniforms.cpp | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/glsl/lower_const_arrays_to_uniforms.cpp
>> b/src/glsl/lower_const_arrays_to_uniforms.cpp
>> index b3c0ee2..700e903 100644
>> --- a/src/glsl/lower_const_arrays_to_uniforms.cpp
>> +++ b/src/glsl/lower_const_arrays_to_uniforms.cpp
>> @@ -49,6 +49,7 @@ public:
>> {
>>instructions = insts;
>>progress = false;
>> + index = 0;
>> }
>>
>> bool run()
>> @@ -62,6 +63,7 @@ public:
>> private:
>> exec_list *instructions;
>> bool progress;
>> + unsigned index;
>> };
>>
>> void
>> @@ -76,8 +78,10 @@ lower_const_array_visitor::handle_rvalue(ir_rvalue
>> **rvalue)
>>
>> void *mem_ctx = ralloc_parent(con);
>>
>> + char *uniform_name = ralloc_asprintf(mem_ctx, "constarray__%d", index++);
>> +
>> ir_variable *uni =
>> - new(mem_ctx) ir_variable(con->type, "constarray", ir_var_uniform);
>> + new(mem_ctx) ir_variable(con->type, uniform_name, ir_var_uniform);
>> uni->constant_initializer = con;
>> uni->constant_value = con;
>> uni->data.has_initializer = true;
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: do all CUBE ALU operations before gradient texture operations (v2)
On Mon, 24 Nov 2014 01:32:36 +0100, Dave Airlie wrote:
From: Dave Airlie
This moves all the CUBE section above the gradients section,
it also fixes a bug with gradient handling in the bytecode handling
where the gradient dst register should be ignored but isn't
causing the subsequent sample_g to fail into a second tex clause.
Bytecode handling is not affected by v2 of this patch, might want to
update the description
v2: avoid changes to bytecode by using spare temps
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 136
+
1 file changed, 72 insertions(+), 64 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 41caac3..e7b39be 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -5095,6 +5095,14 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
inst->Instruction.Opcode == TGSI_OPCODE_TG4)
sampler_src_reg = 2;
+ /* TGSI moves the sampler to src reg 3 for TXD */
+ if (inst->Instruction.Opcode == TGSI_OPCODE_TXD)
+ sampler_src_reg = 3;
+
+ sampler_index_mode = inst->Src[sampler_src_reg].Indirect.Index == 2 ?
2 : 0; // CF_INDEX_1 : CF_INDEX_NONE
+ if (sampler_index_mode)
+ ctx->shader->uses_index_registers = true;
+
src_gpr = tgsi_tex_get_src_gpr(ctx, 0);
if (inst->Texture.Texture == TGSI_TEXTURE_BUFFER) {
@@ -5109,67 +5117,7 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
}
}
- if (inst->Instruction.Opcode == TGSI_OPCODE_TXD) {
- int temp_h, temp_v;
- /* TGSI moves the sampler to src reg 3 for TXD */
- sampler_src_reg = 3;
-
- sampler_index_mode = inst->Src[sampler_src_reg].Indirect.Index == 2 ?
2 : 0; // CF_INDEX_1 : CF_INDEX_NONE
-
- src_loaded = TRUE;
- for (i = 0; i < 3; i++) {
- int treg = r600_get_temp(ctx);
-
- if (i == 0)
- src_gpr = treg;
- else if (i == 1)
- temp_h = treg;
- else
- temp_v = treg;
-
- for (j = 0; j < 4; j++) {
- memset(&alu, 0, sizeof(struct
r600_bytecode_alu));
- alu.op = ALU_OP1_MOV;
-r600_bytecode_src(&alu.src[0],
&ctx->src[i], j);
-alu.dst.sel = treg;
-alu.dst.chan = j;
-if (j == 3)
- alu.last = 1;
-alu.dst.write = 1;
-r = r600_bytecode_add_alu(ctx->bc,
&alu);
-if (r)
-return r;
- }
- }
- for (i = 1; i < 3; i++) {
- /* set gradients h/v */
- memset(&tex, 0, sizeof(struct r600_bytecode_tex));
- tex.op = (i == 1) ? FETCH_OP_SET_GRADIENTS_H :
- FETCH_OP_SET_GRADIENTS_V;
- tex.sampler_id = tgsi_tex_get_src_gpr(ctx,
sampler_src_reg);
- tex.sampler_index_mode = sampler_index_mode;
- tex.resource_id = tex.sampler_id +
R600_MAX_CONST_BUFFERS;
- tex.resource_index_mode = sampler_index_mode;
-
- tex.src_gpr = (i == 1) ? temp_h : temp_v;
- tex.src_sel_x = 0;
- tex.src_sel_y = 1;
- tex.src_sel_z = 2;
- tex.src_sel_w = 3;
-
- tex.dst_gpr = ctx->temp_reg; /* just to avoid confusing the asm
scheduler */
- tex.dst_sel_x = tex.dst_sel_y = tex.dst_sel_z =
tex.dst_sel_w = 7;
- if (inst->Texture.Texture != TGSI_TEXTURE_RECT) {
- tex.coord_type_x = 1;
- tex.coord_type_y = 1;
- tex.coord_type_z = 1;
- tex.coord_type_w = 1;
- }
- r = r600_bytecode_add_tex(ctx->bc, &tex);
- if (r)
- return r;
- }
- } else if (inst->Instruction.Opcode == TGSI_OPCODE_TXP) {
+ if (inst->Instruction.Opcode == TGSI_OPCODE_TXP) {
int out_chan;
/* Add perspective divide */
if (ctx->bc->chip_class == CAYMAN) {
@@ -5233,9 +5181,6 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
src_gpr = ctx->temp_reg;
}
- sampler_index_mode = inst->Src[sampler_src_reg].Indirect.Index == 2 ?
2 : 0; // CF_INDEX_1 : C
[Mesa-dev] [PATCH] r600g: merge the TXQ and BUFFER constant buffers
From: Dave Airlie
We are using 1 more buffer than we have, although in the future the
driver should just end up using one buffer in total probably, this
is a good first step, it merges the txq cube array and buffer info
constants on r600 and evergreen.
this also most likely breaks llvm backend, I've changed it,
but it definitely needs fixes for this.
this fixes a bunch of geom shader textureSize tests on rv635
from gpu reset to pass.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_llvm.c | 3 +-
src/gallium/drivers/r600/r600_pipe.h | 8 +--
src/gallium/drivers/r600/r600_shader.c | 18 --
src/gallium/drivers/r600/r600_state_common.c | 92 +++-
4 files changed, 54 insertions(+), 67 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index c19693a..470c65f 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -23,7 +23,6 @@
#define CONSTANT_BUFFER_0_ADDR_SPACE 8
#define CONSTANT_BUFFER_1_ADDR_SPACE (CONSTANT_BUFFER_0_ADDR_SPACE +
R600_UCP_CONST_BUFFER)
-#define CONSTANT_TXQ_BUFFER (CONSTANT_BUFFER_0_ADDR_SPACE +
R600_TXQ_CONST_BUFFER)
#define LLVM_R600_BUFFER_INFO_CONST_BUFFER \
(CONSTANT_BUFFER_0_ADDR_SPACE + R600_BUFFER_INFO_CONST_BUFFER)
@@ -690,7 +689,7 @@ static void llvm_emit_tex(
if (emit_data->inst->Dst[0].Register.WriteMask & 4) {
LLVMValueRef offset =
lp_build_const_int32(bld_base->base.gallivm, 0);
LLVMValueRef ZLayer =
LLVMBuildExtractElement(gallivm->builder,
- llvm_load_const_buffer(bld_base, offset,
CONSTANT_TXQ_BUFFER),
+ llvm_load_const_buffer(bld_base, offset,
LLVM_R600_BUFFER_INFO_CONST_BUFFER,
lp_build_const_int32(gallivm, 0), "");
emit_data->output[0] =
LLVMBuildInsertElement(gallivm->builder, emit_data->output[0], ZLayer,
lp_build_const_int32(gallivm, 2), "");
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 40b0328..e27e877 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -44,14 +44,13 @@
#define R600_TRACE_CS_DWORDS 7
#define R600_MAX_USER_CONST_BUFFERS 13
-#define R600_MAX_DRIVER_CONST_BUFFERS 4
+#define R600_MAX_DRIVER_CONST_BUFFERS 3
#define R600_MAX_CONST_BUFFERS (R600_MAX_USER_CONST_BUFFERS +
R600_MAX_DRIVER_CONST_BUFFERS)
/* start driver buffers after user buffers */
#define R600_UCP_CONST_BUFFER (R600_MAX_USER_CONST_BUFFERS)
-#define R600_TXQ_CONST_BUFFER (R600_MAX_USER_CONST_BUFFERS + 1)
-#define R600_BUFFER_INFO_CONST_BUFFER (R600_MAX_USER_CONST_BUFFERS + 2)
-#define R600_GS_RING_CONST_BUFFER (R600_MAX_USER_CONST_BUFFERS + 3)
+#define R600_BUFFER_INFO_CONST_BUFFER (R600_MAX_USER_CONST_BUFFERS + 1)
+#define R600_GS_RING_CONST_BUFFER (R600_MAX_USER_CONST_BUFFERS + 2)
/* Currently R600_MAX_CONST_BUFFERS is too large, the hardware only has 16
buffers, but the driver is
* trying to use 17. Avoid accidentally aliasing with user UBOs for
SAMPLE_POSITIONS by using an id<16.
* UCP/SAMPLE_POSITIONS are never accessed by same shader stage so they can
use the same id.
@@ -316,7 +315,6 @@ struct r600_samplerview_state {
uint32_tdirty_mask;
uint32_tcompressed_depthtex_mask; /* which
textures are depth */
uint32_tcompressed_colortex_mask;
- boolean dirty_txq_constants;
boolean dirty_buffer_constants;
};
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index a772dee..61ff162 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -5035,8 +5035,9 @@ static int r600_do_buffer_txq(struct r600_shader_ctx *ctx)
alu.op = ALU_OP1_MOV;
if (ctx->bc->chip_class >= EVERGREEN) {
- alu.src[0].sel = 512 + (id / 4);
- alu.src[0].chan = id % 4;
+ /* channel 0 or 2 of each word */
+ alu.src[0].sel = 512 + (id / 2);
+ alu.src[0].chan = (id % 2) * 2;
} else {
/* r600 we have them at channel 2 of the second dword */
alu.src[0].sel = 512 + (id * 2) + 1;
@@ -5697,9 +5698,16 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
memset(&alu, 0, sizeof(struct r600_bytecode_alu));
alu.op = ALU_OP1_MOV;
- alu.src[0].sel = 512 + (id / 4);
- alu.src[0].kc_bank = R600_TXQ_CONST_BUFFER;
- alu.src[0].chan = id % 4;
+ if (ctx->bc->chip_class >= EVERGREEN) {
+ /* channel 1 or 3 of each word */
+ alu.src[0].sel = 512 + (id / 2);
+
Re: [Mesa-dev] [PATCH 2/2] i965/draw state: Allow state upload to proceed when inputs are not set
On 2014-11-22 23:50:29, Kenneth Graunke wrote:
> On Saturday, November 22, 2014 11:26:39 PM Jordan Justen wrote:
> > On 2014-11-22 17:33:54, Kenneth Graunke wrote:
> > > On Saturday, November 22, 2014 12:02:31 PM Jordan Justen wrote:
> > > > For drawing the OpenGL API should validate this before we try to upload
> > > > the
> > > > state.
> > > >
> > > > For compute, these might not be set.
> > > >
> > > > Signed-off-by: Jordan Justen
> > > > ---
> > > > src/mesa/drivers/dri/i965/brw_draw_upload.c | 4
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
> > > > b/src/mesa/drivers/dri/i965/brw_draw_upload.c
> > > > index 5a12439..28136e2 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
> > > > @@ -433,6 +433,10 @@ brw_prepare_vertices(struct brw_context *brw)
> > > >struct brw_vertex_element *input = &brw->vb.inputs[i];
> > > >
> > > >vs_inputs &= ~BITFIELD64_BIT(i);
> > > > +
> > > > + if (!input->glarray)
> > > > + continue;
> > > > +
> > > >brw->vb.enabled[brw->vb.nr_enabled++] = input;
> > > > }
> > >
> > > Seems like you don't want to be calling this code at all when doing
> > > compute.
> > >
> > > The draw upload code is already complicated and difficult to understand;
> > > although this is a small addition, the "Inputs can be NULL?!?!?" question
> > > readers might have could add to the confusion. Which is fine, if compute
> > > needs to hit this code...but if it doesn't need it, skipping it altogether
> > > would be clearer and simpler.
> > >
> > > Does compute actually want 3DSTATE_VERTEX_BUFFERS/ELEMENTS? Does it use
> > > 3DPRIMITIVE?
> >
> > No. But, as I understanded your previous feedback, you didn't want to
> > have separate state tracking for compute.
>
> Not necessarily.
>
> Jordan, could you send out a list of the command packets and state needed
> to do meaningful compute work? I think that would help me understand
> what's required. INTEL_DEBUG=bat would show what you're currently emitting.
Hmm. Maybe I overreacted to your previous feedback.
I basically assumed that the separate pipeline state tracking was a
no-go and moved forward assuming I'd just merge the compute state into
the current set of state upload.
In order to know how much overlaps, I'd need to separate it back out.
> My assumption so far (which I'd like to confirm with the above list) is that
> there's actually very little overlap between normal 3D drawing and general
> compute work. I also know that compute shaders are kicked off via separate
> glDispatchCompute and glDispatchComputeIndirect functions. I don't really
> understand why we're even hitting the draw_prims driver hook. If there's
> really little overlap, then creating a totally separate driver hook might
> make more sense.
These are state upload based code paths. We're not going through
draw_prims.
These paths were not hit previously when we were using Paul's separate
state pipelines.
> Another idea I've had is that we could use a separate hardware context
> (brw->hw_ctx_3d and brw->hw_ctx_compute), so both the 3D and compute pipes
> could operate without interfering with one another - we wouldn't need to
> consider state dirtied by one or the other.
In order to do something like this, I think we'd need to go back to
tracking the state independently for a draw vs. compute. We could then
either re-emit state to a single context or separate contexts if we
wanted.
But, I'm not sure this is 100% achievable. ("we wouldn't need to
consider state dirtied by one or the other") It is not like we set the
GL state to either draw or compute. So, if state changes, we need to
mark it as dirty for both, and be sure to update based on that before
either a draw or compute.
I guess I need to better understand what needed to change from Paul's
separate pipelines series, because I (too quickly) assumed it had been
NAKed in its entirety.
One idea that is a bit different from Paul's implementation might be
to add a new bitmap to brw_tracked_state which allows a state object
to indicate draw and/or compute applicability. We could then keep a
single array of state objects.
Another idea is that we could retain a single set of dirty bits when
marking state as dirty, but duplicate it for the separate pipelines at
state upload time. This might be able to avoid the somewhat ugly state
macros. (These macros were a common source of conflicts during
rebases.)
-Jordan
> Again, I think seeing a list of commands would help us figure out the
> best solution (hopefully both efficient and simple).
>
> > Therefore, when we we upload dirty state before running compute
> > operations, it is possible (and apparently likely) that the
> > brw_vertices state atom will call this code.
> >
> > When I removed the separate compute state tracking pipeline, I found I
> > only needed these two c
[Mesa-dev] [PATCH 08/11] st/nine: Fix setting of the shift modifier in nine_shader
From: Axel Davy
It is an sint_4, but it was stored in a uint_8...
The code using it was acting as if it was signed.
Problem found thanks to Coverity
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_shader.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_shader.c
b/src/gallium/state_trackers/nine/nine_shader.c
index cc027b4..7d5622b 100644
--- a/src/gallium/state_trackers/nine/nine_shader.c
+++ b/src/gallium/state_trackers/nine/nine_shader.c
@@ -239,7 +239,7 @@ struct sm1_dst_param
BYTE file;
BYTE mask;
BYTE mod;
-BYTE shift; /* sint4 */
+int8_t shift; /* sint4 */
BYTE type;
};
@@ -2535,6 +2535,7 @@ sm1_parse_get_param(struct shader_translator *tx, DWORD
*reg, DWORD *rel)
static void
sm1_parse_dst_param(struct sm1_dst_param *dst, DWORD tok)
{
+uint8_t shift;
dst->file =
(tok & D3DSP_REGTYPE_MASK) >> D3DSP_REGTYPE_SHIFT |
(tok & D3DSP_REGTYPE_MASK2) >> D3DSP_REGTYPE_SHIFT2;
@@ -2543,7 +2544,8 @@ sm1_parse_dst_param(struct sm1_dst_param *dst, DWORD tok)
dst->rel = NULL;
dst->mask = (tok & NINED3DSP_WRITEMASK_MASK) >> NINED3DSP_WRITEMASK_SHIFT;
dst->mod = (tok & D3DSP_DSTMOD_MASK) >> D3DSP_DSTMOD_SHIFT;
-dst->shift = (tok & D3DSP_DSTSHIFT_MASK) >> D3DSP_DSTSHIFT_SHIFT;
+shift = (tok & D3DSP_DSTSHIFT_MASK) >> D3DSP_DSTSHIFT_SHIFT;
+dst->shift = (shift & 0x8) ? -(shift & 0x7) : shift & 0x7;
}
static void
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/11] st/nine: Refactor Resource9 BaseTexture9 Surface9 and Texture9 initialization
From: Axel Davy
First change is to pass initResource argument to initialise the resource
field in Resource9 instead of in the parents.
Second change is to pass Usage argument, instead of letting the parent
classes set the usage field of the Resource9 structure.
Third change fixes a bug, preventing Half-Life 2 Lost Coast from working
properly, is to remove the data field from Resource9, put it in Surface9,
which was the only user, and add flag to Surface9 to know if it has created
the data or not. Surface9 dtor frees the data only if it created it.
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/adapter9.c | 2 +-
src/gallium/state_trackers/nine/basetexture9.c | 23 +++--
src/gallium/state_trackers/nine/basetexture9.h | 5 +-
src/gallium/state_trackers/nine/cubetexture9.c | 9 +-
src/gallium/state_trackers/nine/device9.c| 19 ++--
src/gallium/state_trackers/nine/device9.h| 7 +-
src/gallium/state_trackers/nine/device9ex.c | 6 +-
src/gallium/state_trackers/nine/indexbuffer9.c | 4 +-
src/gallium/state_trackers/nine/resource9.c | 13 +--
src/gallium/state_trackers/nine/resource9.h | 6 +-
src/gallium/state_trackers/nine/surface9.c | 112 ++-
src/gallium/state_trackers/nine/surface9.h | 7 +-
src/gallium/state_trackers/nine/swapchain9.c | 6 +-
src/gallium/state_trackers/nine/texture9.c | 51 ---
src/gallium/state_trackers/nine/vertexbuffer9.c | 4 +-
src/gallium/state_trackers/nine/volumetexture9.c | 7 +-
16 files changed, 106 insertions(+), 175 deletions(-)
diff --git a/src/gallium/state_trackers/nine/adapter9.c
b/src/gallium/state_trackers/nine/adapter9.c
index 8d574de..e409d5f 100644
--- a/src/gallium/state_trackers/nine/adapter9.c
+++ b/src/gallium/state_trackers/nine/adapter9.c
@@ -990,7 +990,7 @@ NineAdapter9_CreateDevice( struct NineAdapter9 *This,
params.BehaviorFlags = BehaviorFlags;
hr = NineDevice9_new(screen, ¶ms, &caps, pPresentationParameters,
- pD3D9, pPresentationGroup, This->ctx,
+ pD3D9, pPresentationGroup, This->ctx, FALSE, NULL,
(struct NineDevice9 **)ppReturnedDeviceInterface);
if (FAILED(hr)) {
DBG("Failed to create device.\n");
diff --git a/src/gallium/state_trackers/nine/basetexture9.c
b/src/gallium/state_trackers/nine/basetexture9.c
index 89f6269..7bf2f56 100644
--- a/src/gallium/state_trackers/nine/basetexture9.c
+++ b/src/gallium/state_trackers/nine/basetexture9.c
@@ -41,25 +41,28 @@
HRESULT
NineBaseTexture9_ctor( struct NineBaseTexture9 *This,
struct NineUnknownParams *pParams,
+ struct pipe_resource *initResource,
D3DRESOURCETYPE Type,
- D3DPOOL Pool )
+ D3DFORMAT format,
+ D3DPOOL Pool,
+ DWORD Usage)
{
-BOOL alloc = (Pool == D3DPOOL_DEFAULT) && !This->base.resource &&
-(This->format != D3DFMT_NULL);
+BOOL alloc = (Pool == D3DPOOL_DEFAULT) && !initResource &&
+(format != D3DFMT_NULL);
HRESULT hr;
-DWORD usage = This->base.usage;
-user_assert(!(usage & (D3DUSAGE_RENDERTARGET | D3DUSAGE_DEPTHSTENCIL)) ||
+user_assert(!(Usage & (D3DUSAGE_RENDERTARGET | D3DUSAGE_DEPTHSTENCIL)) ||
Pool == D3DPOOL_DEFAULT, D3DERR_INVALIDCALL);
-user_assert(!(usage & D3DUSAGE_DYNAMIC) ||
+user_assert(!(Usage & D3DUSAGE_DYNAMIC) ||
Pool != D3DPOOL_MANAGED, D3DERR_INVALIDCALL);
-hr = NineResource9_ctor(&This->base, pParams, alloc, Type, Pool);
+hr = NineResource9_ctor(&This->base, pParams, initResource, alloc, Type,
Pool, Usage);
if (FAILED(hr))
return hr;
+This->format = format;
This->pipe = pParams->device->pipe;
-This->mipfilter = (This->base.usage & D3DUSAGE_AUTOGENMIPMAP) ?
+This->mipfilter = (Usage & D3DUSAGE_AUTOGENMIPMAP) ?
D3DTEXF_LINEAR : D3DTEXF_NONE;
This->lod = 0;
This->lod_resident = -1;
@@ -490,9 +493,9 @@ NineBaseTexture9_PreLoad( struct NineBaseTexture9 *This )
void
NineBaseTexture9_Dump( struct NineBaseTexture9 *This )
{
-DBG("\nNineBaseTexture9(%p->%p/%p): Pool=%s Type=%s Usage=%s\n"
+DBG("\nNineBaseTexture9(%p->NULL/%p): Pool=%s Type=%s Usage=%s\n"
"Format=%s Dims=%ux%ux%u/%u LastLevel=%u Lod=%u(%u)\n", This,
-This->base.resource, This->base.data,
+This->base.resource,
nine_D3DPOOL_to_str(This->base.pool),
nine_D3DRTYPE_to_str(This->base.type),
nine_D3DUSAGE_to_str(This->base.usage),
diff --git a/src/gallium/state_trackers/nine/basetexture9.h
b/src/gallium/state_trackers/nine/basetexture9.h
index d615376..0062771 100644
--- a/src/gallium/state_trackers/nine/basetexture9.h
+++ b/src/gallium/state_trackers/nine/basetexture9.h
@@ -59,8 +59,
[Mesa-dev] [PATCH 02/11] st/nine: call DBG() at more external entry points
From: Stanislaw Halik
Cc: "10.4"
Reviewed-by: David Heidelberg
Reviewed-by: Axel Davy
Signed-off-by: Stanislaw Halik
---
src/gallium/state_trackers/nine/basetexture9.c | 17
src/gallium/state_trackers/nine/cubetexture9.c | 17
src/gallium/state_trackers/nine/device9.c | 46 ++
src/gallium/state_trackers/nine/device9ex.c| 15 +++
src/gallium/state_trackers/nine/iunknown.c | 2 +
src/gallium/state_trackers/nine/pixelshader9.c | 4 ++
src/gallium/state_trackers/nine/query9.c | 7
src/gallium/state_trackers/nine/resource9.c| 11 ++
src/gallium/state_trackers/nine/stateblock9.c | 3 ++
src/gallium/state_trackers/nine/surface9.c | 7
src/gallium/state_trackers/nine/swapchain9.c | 5 +++
src/gallium/state_trackers/nine/swapchain9ex.c | 4 ++
src/gallium/state_trackers/nine/texture9.c | 5 +++
.../state_trackers/nine/vertexdeclaration9.c | 5 +++
src/gallium/state_trackers/nine/vertexshader9.c| 3 ++
src/gallium/state_trackers/nine/volume9.c | 8
src/gallium/state_trackers/nine/volumetexture9.c | 12 ++
17 files changed, 171 insertions(+)
diff --git a/src/gallium/state_trackers/nine/basetexture9.c
b/src/gallium/state_trackers/nine/basetexture9.c
index 7bf2f56..12da1e0 100644
--- a/src/gallium/state_trackers/nine/basetexture9.c
+++ b/src/gallium/state_trackers/nine/basetexture9.c
@@ -51,6 +51,9 @@ NineBaseTexture9_ctor( struct NineBaseTexture9 *This,
(format != D3DFMT_NULL);
HRESULT hr;
+DBG("This=%p, pParams=%p initResource=%p Type=%d format=%d Pool=%d
Usage=%d\n",
+This, pParams, initResource, Type, format, Pool, Usage);
+
user_assert(!(Usage & (D3DUSAGE_RENDERTARGET | D3DUSAGE_DEPTHSTENCIL)) ||
Pool == D3DPOOL_DEFAULT, D3DERR_INVALIDCALL);
user_assert(!(Usage & D3DUSAGE_DYNAMIC) ||
@@ -93,6 +96,8 @@ NineBaseTexture9_SetLOD( struct NineBaseTexture9 *This,
{
DWORD old = This->lod;
+DBG("This=%p LODNew=%d\n", This, LODNew);
+
user_assert(This->base.pool == D3DPOOL_MANAGED, 0);
This->lod = MIN2(LODNew, This->base.info.last_level);
@@ -106,12 +111,16 @@ NineBaseTexture9_SetLOD( struct NineBaseTexture9 *This,
DWORD WINAPI
NineBaseTexture9_GetLOD( struct NineBaseTexture9 *This )
{
+DBG("This=%p\n", This);
+
return This->lod;
}
DWORD WINAPI
NineBaseTexture9_GetLevelCount( struct NineBaseTexture9 *This )
{
+DBG("This=%p\n", This);
+
if (This->base.usage & D3DUSAGE_AUTOGENMIPMAP)
return 1;
return This->base.info.last_level + 1;
@@ -121,6 +130,8 @@ HRESULT WINAPI
NineBaseTexture9_SetAutoGenFilterType( struct NineBaseTexture9 *This,
D3DTEXTUREFILTERTYPE FilterType )
{
+DBG("This=%p FilterType=%d\n", This, FilterType);
+
if (!(This->base.usage & D3DUSAGE_AUTOGENMIPMAP))
return D3D_OK;
user_assert(FilterType != D3DTEXF_NONE, D3DERR_INVALIDCALL);
@@ -133,6 +144,8 @@ NineBaseTexture9_SetAutoGenFilterType( struct
NineBaseTexture9 *This,
D3DTEXTUREFILTERTYPE WINAPI
NineBaseTexture9_GetAutoGenFilterType( struct NineBaseTexture9 *This )
{
+DBG("This=%p\n", This);
+
return This->mipfilter;
}
@@ -433,6 +446,8 @@ NineBaseTexture9_UpdateSamplerView( struct NineBaseTexture9
*This,
struct pipe_sampler_view templ;
uint8_t swizzle[4];
+DBG("This=%p sRGB=%d\n", This, sRGB);
+
if (unlikely(!resource)) {
if (unlikely(This->format == D3DFMT_NULL))
return D3D_OK;
@@ -485,6 +500,8 @@ NineBaseTexture9_UpdateSamplerView( struct NineBaseTexture9
*This,
void WINAPI
NineBaseTexture9_PreLoad( struct NineBaseTexture9 *This )
{
+DBG("This=%p\n", This);
+
if (This->dirty && This->base.pool == D3DPOOL_MANAGED)
NineBaseTexture9_UploadSelf(This);
}
diff --git a/src/gallium/state_trackers/nine/cubetexture9.c
b/src/gallium/state_trackers/nine/cubetexture9.c
index 5ef09f7..9f5d8e2 100644
--- a/src/gallium/state_trackers/nine/cubetexture9.c
+++ b/src/gallium/state_trackers/nine/cubetexture9.c
@@ -42,6 +42,11 @@ NineCubeTexture9_ctor( struct NineCubeTexture9 *This,
D3DSURFACE_DESC sfdesc;
HRESULT hr;
+DBG("This=%p pParams=%p EdgeLength=%u Levels=%u Usage=%d "
+"Format=%d Pool=%d pSharedHandle=%p\n",
+This, pParams, EdgeLength, Levels, Usage,
+Format, Pool, pSharedHandle);
+
user_assert(!(Usage & D3DUSAGE_AUTOGENMIPMAP) ||
(Pool != D3DPOOL_SYSTEMMEM && Levels <= 1),
D3DERR_INVALIDCALL);
@@ -135,6 +140,8 @@ NineCubeTexture9_GetLevelDesc( struct NineCubeTexture9
*This,
UINT Level,
D3DSURFACE_DESC *pDesc )
{
+DBG("This=%p Level=%u pDesc=%p\n", This, Level, pDesc);
+
user_assert(Level <= This->base.base.info.last_level, D3DERR_INVALIDCALL);
user_assert(Level == 0 || !(This
[Mesa-dev] [PATCH 06/11] st/nine: fix wrong variable reset
From: Axel Davy Error detected by Coverity (COPY_PAST_ERROR) Cc: "10.4" Signed-off-by: Axel Davy Signed-off-by: David Heidelberg --- src/gallium/state_trackers/nine/nine_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/nine/nine_state.c b/src/gallium/state_trackers/nine/nine_state.c index 0215d08..6924449 100644 --- a/src/gallium/state_trackers/nine/nine_state.c +++ b/src/gallium/state_trackers/nine/nine_state.c @@ -400,7 +400,7 @@ update_constants(struct NineDevice9 *device, unsigned shader_type) const_i = &device->state.ps_const_i[0][0]; dirty_b = device->state.changed.ps_const_b; -device->state.changed.vs_const_b = 0; +device->state.changed.ps_const_b = 0; const_b = device->state.ps_const_b; b_true = device->ps_bool_true; -- 2.1.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/11] st/nine: remove unused pipe_viewport_state::translate[3] and scale[3]
2efabd9f5a711a7f6cd1846630244b7814bf25b3 removed them as unused. This caused random memory overwrites (reported by Coverity). Cc: "10.4" Reviewed-by: Marek Olšák Reviewed-by: Axel Davy Signed-off-by: David Heidelberg --- src/gallium/state_trackers/nine/nine_state.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/gallium/state_trackers/nine/nine_state.c b/src/gallium/state_trackers/nine/nine_state.c index 6924449..37de6a3 100644 --- a/src/gallium/state_trackers/nine/nine_state.c +++ b/src/gallium/state_trackers/nine/nine_state.c @@ -141,11 +141,9 @@ update_viewport(struct NineDevice9 *device) pvport.scale[0] = (float)vport->Width * 0.5f; pvport.scale[1] = (float)vport->Height * -0.5f; pvport.scale[2] = vport->MaxZ - vport->MinZ; -pvport.scale[3] = 1.0f; pvport.translate[0] = (float)vport->Width * 0.5f + (float)vport->X; pvport.translate[1] = (float)vport->Height * 0.5f + (float)vport->Y; pvport.translate[2] = vport->MinZ; -pvport.translate[3] = 0.0f; pipe->set_viewport_states(pipe, 0, 1, &pvport); } -- 2.1.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/11] st/nine: fix wrong variable reset
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote: > From: Axel Davy > > Error detected by Coverity (COPY_PAST_ERROR) Probably COPY_PASTE_ERROR? Didn't check... > > Cc: "10.4" > Signed-off-by: Axel Davy > Signed-off-by: David Heidelberg Reviewed-by: Ilia Mirkin > --- > src/gallium/state_trackers/nine/nine_state.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/state_trackers/nine/nine_state.c > b/src/gallium/state_trackers/nine/nine_state.c > index 0215d08..6924449 100644 > --- a/src/gallium/state_trackers/nine/nine_state.c > +++ b/src/gallium/state_trackers/nine/nine_state.c > @@ -400,7 +400,7 @@ update_constants(struct NineDevice9 *device, unsigned > shader_type) > const_i = &device->state.ps_const_i[0][0]; > > dirty_b = device->state.changed.ps_const_b; > -device->state.changed.vs_const_b = 0; > +device->state.changed.ps_const_b = 0; > const_b = device->state.ps_const_b; > b_true = device->ps_bool_true; > > -- > 2.1.3 > > ___ > 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] [PATCH 07/11] st/nine: remove unused pipe_viewport_state::translate[3] and scale[3]
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote: > 2efabd9f5a711a7f6cd1846630244b7814bf25b3 removed them as unused. > > This caused random memory overwrites (reported by Coverity). > > Cc: "10.4" > Reviewed-by: Marek Olšák > Reviewed-by: Axel Davy > Signed-off-by: David Heidelberg Reviewed-by: Ilia Mirkin > --- > src/gallium/state_trackers/nine/nine_state.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/src/gallium/state_trackers/nine/nine_state.c > b/src/gallium/state_trackers/nine/nine_state.c > index 6924449..37de6a3 100644 > --- a/src/gallium/state_trackers/nine/nine_state.c > +++ b/src/gallium/state_trackers/nine/nine_state.c > @@ -141,11 +141,9 @@ update_viewport(struct NineDevice9 *device) > pvport.scale[0] = (float)vport->Width * 0.5f; > pvport.scale[1] = (float)vport->Height * -0.5f; > pvport.scale[2] = vport->MaxZ - vport->MinZ; > -pvport.scale[3] = 1.0f; > pvport.translate[0] = (float)vport->Width * 0.5f + (float)vport->X; > pvport.translate[1] = (float)vport->Height * 0.5f + (float)vport->Y; > pvport.translate[2] = vport->MinZ; > -pvport.translate[3] = 0.0f; > > pipe->set_viewport_states(pipe, 0, 1, &pvport); > } > -- > 2.1.3 > > ___ > 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] [PATCH 08/11] st/nine: Fix setting of the shift modifier in nine_shader
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote:
> From: Axel Davy
>
> It is an sint_4, but it was stored in a uint_8...
> The code using it was acting as if it was signed.
>
> Problem found thanks to Coverity
>
> Cc: "10.4"
> Tested-by: David Heidelberg
> Signed-off-by: Axel Davy
Reviewed-by: Ilia Mirkin
> ---
> src/gallium/state_trackers/nine/nine_shader.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/nine/nine_shader.c
> b/src/gallium/state_trackers/nine/nine_shader.c
> index cc027b4..7d5622b 100644
> --- a/src/gallium/state_trackers/nine/nine_shader.c
> +++ b/src/gallium/state_trackers/nine/nine_shader.c
> @@ -239,7 +239,7 @@ struct sm1_dst_param
> BYTE file;
> BYTE mask;
> BYTE mod;
> -BYTE shift; /* sint4 */
> +int8_t shift; /* sint4 */
> BYTE type;
> };
>
> @@ -2535,6 +2535,7 @@ sm1_parse_get_param(struct shader_translator *tx, DWORD
> *reg, DWORD *rel)
> static void
> sm1_parse_dst_param(struct sm1_dst_param *dst, DWORD tok)
> {
> +uint8_t shift;
> dst->file =
> (tok & D3DSP_REGTYPE_MASK) >> D3DSP_REGTYPE_SHIFT |
> (tok & D3DSP_REGTYPE_MASK2) >> D3DSP_REGTYPE_SHIFT2;
> @@ -2543,7 +2544,8 @@ sm1_parse_dst_param(struct sm1_dst_param *dst, DWORD
> tok)
> dst->rel = NULL;
> dst->mask = (tok & NINED3DSP_WRITEMASK_MASK) >>
> NINED3DSP_WRITEMASK_SHIFT;
> dst->mod = (tok & D3DSP_DSTMOD_MASK) >> D3DSP_DSTMOD_SHIFT;
> -dst->shift = (tok & D3DSP_DSTSHIFT_MASK) >> D3DSP_DSTSHIFT_SHIFT;
> +shift = (tok & D3DSP_DSTSHIFT_MASK) >> D3DSP_DSTSHIFT_SHIFT;
> +dst->shift = (shift & 0x8) ? -(shift & 0x7) : shift & 0x7;
> }
>
> static void
> --
> 2.1.3
>
> ___
> 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] [PATCH 01/11] st/nine: Refactor Resource9 BaseTexture9 Surface9 and Texture9 initialization
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote:
> From: Axel Davy
>
> First change is to pass initResource argument to initialise the resource
> field in Resource9 instead of in the parents.
>
> Second change is to pass Usage argument, instead of letting the parent
> classes set the usage field of the Resource9 structure.
>
> Third change fixes a bug, preventing Half-Life 2 Lost Coast from working
> properly, is to remove the data field from Resource9, put it in Surface9,
> which was the only user, and add flag to Surface9 to know if it has created
> the data or not. Surface9 dtor frees the data only if it created it.
A few comments:
(a) If a commit log contains "first change, second change, third
change", that's an indicator that it should have been 3 changes. It's
changing inter-related bits, so it'll be a pain to tease back apart.
(b) This is a big commit to be backporting to 10.4. I guess nine is
new, so not a huge deal. But it's not a good habit to get into.
Realistically, you'll have a hard time getting such a large
multi-function commit reviewed. Perhaps that's a reality for all of
nine, dunno. Just a thought.
>
> Cc: "10.4"
> Tested-by: David Heidelberg
> Signed-off-by: Axel Davy
> ---
> src/gallium/state_trackers/nine/adapter9.c | 2 +-
> src/gallium/state_trackers/nine/basetexture9.c | 23 +++--
> src/gallium/state_trackers/nine/basetexture9.h | 5 +-
> src/gallium/state_trackers/nine/cubetexture9.c | 9 +-
> src/gallium/state_trackers/nine/device9.c| 19 ++--
> src/gallium/state_trackers/nine/device9.h| 7 +-
> src/gallium/state_trackers/nine/device9ex.c | 6 +-
> src/gallium/state_trackers/nine/indexbuffer9.c | 4 +-
> src/gallium/state_trackers/nine/resource9.c | 13 +--
> src/gallium/state_trackers/nine/resource9.h | 6 +-
> src/gallium/state_trackers/nine/surface9.c | 112
> ++-
> src/gallium/state_trackers/nine/surface9.h | 7 +-
> src/gallium/state_trackers/nine/swapchain9.c | 6 +-
> src/gallium/state_trackers/nine/texture9.c | 51 ---
> src/gallium/state_trackers/nine/vertexbuffer9.c | 4 +-
> src/gallium/state_trackers/nine/volumetexture9.c | 7 +-
> 16 files changed, 106 insertions(+), 175 deletions(-)
>
> diff --git a/src/gallium/state_trackers/nine/adapter9.c
> b/src/gallium/state_trackers/nine/adapter9.c
> index 8d574de..e409d5f 100644
> --- a/src/gallium/state_trackers/nine/adapter9.c
> +++ b/src/gallium/state_trackers/nine/adapter9.c
> @@ -990,7 +990,7 @@ NineAdapter9_CreateDevice( struct NineAdapter9 *This,
> params.BehaviorFlags = BehaviorFlags;
>
> hr = NineDevice9_new(screen, ¶ms, &caps, pPresentationParameters,
> - pD3D9, pPresentationGroup, This->ctx,
> + pD3D9, pPresentationGroup, This->ctx, FALSE, NULL,
> (struct NineDevice9 **)ppReturnedDeviceInterface);
> if (FAILED(hr)) {
> DBG("Failed to create device.\n");
> diff --git a/src/gallium/state_trackers/nine/basetexture9.c
> b/src/gallium/state_trackers/nine/basetexture9.c
> index 89f6269..7bf2f56 100644
> --- a/src/gallium/state_trackers/nine/basetexture9.c
> +++ b/src/gallium/state_trackers/nine/basetexture9.c
> @@ -41,25 +41,28 @@
> HRESULT
> NineBaseTexture9_ctor( struct NineBaseTexture9 *This,
> struct NineUnknownParams *pParams,
> + struct pipe_resource *initResource,
> D3DRESOURCETYPE Type,
> - D3DPOOL Pool )
> + D3DFORMAT format,
> + D3DPOOL Pool,
> + DWORD Usage)
> {
> -BOOL alloc = (Pool == D3DPOOL_DEFAULT) && !This->base.resource &&
> -(This->format != D3DFMT_NULL);
> +BOOL alloc = (Pool == D3DPOOL_DEFAULT) && !initResource &&
> +(format != D3DFMT_NULL);
> HRESULT hr;
> -DWORD usage = This->base.usage;
>
> -user_assert(!(usage & (D3DUSAGE_RENDERTARGET | D3DUSAGE_DEPTHSTENCIL)) ||
> +user_assert(!(Usage & (D3DUSAGE_RENDERTARGET | D3DUSAGE_DEPTHSTENCIL)) ||
> Pool == D3DPOOL_DEFAULT, D3DERR_INVALIDCALL);
> -user_assert(!(usage & D3DUSAGE_DYNAMIC) ||
> +user_assert(!(Usage & D3DUSAGE_DYNAMIC) ||
> Pool != D3DPOOL_MANAGED, D3DERR_INVALIDCALL);
>
> -hr = NineResource9_ctor(&This->base, pParams, alloc, Type, Pool);
> +hr = NineResource9_ctor(&This->base, pParams, initResource, alloc, Type,
> Pool, Usage);
> if (FAILED(hr))
> return hr;
>
> +This->format = format;
> This->pipe = pParams->device->pipe;
> -This->mipfilter = (This->base.usage & D3DUSAGE_AUTOGENMIPMAP) ?
> +This->mipfilter = (Usage & D3DUSAGE_AUTOGENMIPMAP) ?
> D3DTEXF_LINEAR : D3DTEXF_NONE;
> This->lod = 0;
> This->lod_resident = -1;
> @@ -490,9 +493,9 @@ NineBaseTexture9_PreLoad( struct NineBaseTexture9 *This )
> void
>
[Mesa-dev] [PATCH 11/11] st/nine: return S_FALSE instead of INVALIDCALL when in building query state
From: Axel Davy
It is the same behaviour as wine has.
Cc: "10.4"
Reviewed-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/query9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/query9.c
b/src/gallium/state_trackers/nine/query9.c
index f32f572..c244379 100644
--- a/src/gallium/state_trackers/nine/query9.c
+++ b/src/gallium/state_trackers/nine/query9.c
@@ -255,7 +255,7 @@ NineQuery9_GetData( struct NineQuery9 *This,
DBG("This=%p pData=%p dwSize=%d dwGetDataFlags=%d\n",
This, pData, dwSize, dwGetDataFlags);
-user_assert(This->state != NINE_QUERY_STATE_RUNNING, D3DERR_INVALIDCALL);
+user_assert(This->state != NINE_QUERY_STATE_RUNNING, S_FALSE);
user_assert(dwSize == 0 || pData, D3DERR_INVALIDCALL);
user_assert(dwGetDataFlags == 0 ||
dwGetDataFlags == D3DGETDATA_FLUSH, D3DERR_INVALIDCALL);
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/11] st/nine: Handle queries not supported by the driver
From: Axel Davy
Cc: "10.4"
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c | 2 +-
src/gallium/state_trackers/nine/query9.c | 52 ---
src/gallium/state_trackers/nine/query9.h | 2 +-
3 files changed, 42 insertions(+), 14 deletions(-)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index d48f47d..f723294 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -3360,7 +3360,7 @@ NineDevice9_CreateQuery( struct NineDevice9 *This,
DBG("This=%p Type=%d ppQuery=%p\n", This, Type, ppQuery);
if (!ppQuery)
-return nine_is_query_supported(Type);
+return nine_is_query_supported(This->screen, Type);
hr = NineQuery9_new(This, &query, Type);
if (FAILED(hr))
diff --git a/src/gallium/state_trackers/nine/query9.c
b/src/gallium/state_trackers/nine/query9.c
index 34dfec7..f32f572 100644
--- a/src/gallium/state_trackers/nine/query9.c
+++ b/src/gallium/state_trackers/nine/query9.c
@@ -23,16 +23,27 @@
#include "device9.h"
#include "query9.h"
#include "nine_helpers.h"
+#include "pipe/p_screen.h"
#include "pipe/p_context.h"
#include "util/u_math.h"
+#include "os/os_time.h"
#include "nine_dump.h"
#define DBG_CHANNEL DBG_QUERY
#define QUERY_TYPE_MAP_CASE(a, b) case D3DQUERYTYPE_##a: return PIPE_QUERY_##b
static inline unsigned
-d3dquerytype_to_pipe_query(D3DQUERYTYPE type)
+d3dquerytype_to_pipe_query(struct pipe_screen *screen, D3DQUERYTYPE type)
{
+if ((type == D3DQUERYTYPE_OCCLUSION &&
+!screen->get_param(screen, PIPE_CAP_OCCLUSION_QUERY)) ||
+((type == D3DQUERYTYPE_TIMESTAMP || type == D3DQUERYTYPE_TIMESTAMPFREQ
||
+type == D3DQUERYTYPE_TIMESTAMPDISJOINT)&&
+!screen->get_param(screen, PIPE_CAP_QUERY_TIMESTAMP)) ||
+(type == D3DQUERYTYPE_VERTEXSTATS &&
+!screen->get_param(screen, PIPE_CAP_QUERY_PIPELINE_STATISTICS)))
+return PIPE_QUERY_TYPES;
+
switch (type) {
QUERY_TYPE_MAP_CASE(EVENT, GPU_FINISHED);
QUERY_TYPE_MAP_CASE(OCCLUSION, OCCLUSION_COUNTER);
@@ -84,9 +95,9 @@ nine_query_result_size(D3DQUERYTYPE type)
}
HRESULT
-nine_is_query_supported(D3DQUERYTYPE type)
+nine_is_query_supported(struct pipe_screen *screen, D3DQUERYTYPE type)
{
-const unsigned ptype = d3dquerytype_to_pipe_query(type);
+const unsigned ptype = d3dquerytype_to_pipe_query(screen, type);
user_assert(ptype != ~0, D3DERR_INVALIDCALL);
@@ -104,7 +115,7 @@ NineQuery9_ctor( struct NineQuery9 *This,
D3DQUERYTYPE Type )
{
struct pipe_context *pipe = pParams->device->pipe;
-const unsigned ptype = d3dquerytype_to_pipe_query(Type);
+const unsigned ptype = d3dquerytype_to_pipe_query(pParams->device->screen,
Type);
HRESULT hr;
DBG("This=%p pParams=%p Type=%d\n", This, pParams, Type);
@@ -282,22 +293,39 @@ NineQuery9_GetData( struct NineQuery9 *This,
nresult.b = presult.b;
break;
case D3DQUERYTYPE_OCCLUSION:
-nresult.dw = presult.u64;
+if (This->pq)
+nresult.dw = presult.u64;
+else
+nresult.dw = 0;
break;
case D3DQUERYTYPE_TIMESTAMP:
-nresult.u64 = presult.u64;
+if (This->pq)
+nresult.u64 = presult.u64;
+else
+nresult.u64 = os_time_get_nano();
break;
case D3DQUERYTYPE_TIMESTAMPDISJOINT:
-nresult.b = presult.timestamp_disjoint.disjoint;
+if (This->pq)
+nresult.b = presult.timestamp_disjoint.disjoint;
+else
+nresult.b = FALSE;
break;
case D3DQUERYTYPE_TIMESTAMPFREQ:
-nresult.u64 = presult.timestamp_disjoint.frequency;
+if (This->pq)
+nresult.u64 = presult.timestamp_disjoint.frequency;
+else
+nresult.u64 = 1; /* dummy value */
break;
case D3DQUERYTYPE_VERTEXSTATS:
-nresult.vertexstats.NumRenderedTriangles =
-presult.pipeline_statistics.c_invocations;
-nresult.vertexstats.NumExtraClippingTriangles =
-presult.pipeline_statistics.c_primitives;
+if (This->pq) {
+nresult.vertexstats.NumRenderedTriangles =
+presult.pipeline_statistics.c_invocations;
+nresult.vertexstats.NumExtraClippingTriangles =
+presult.pipeline_statistics.c_primitives;
+} else {
+nresult.vertexstats.NumRenderedTriangles = 1;
+nresult.vertexstats.NumExtraClippingTriangles = 0;
+}
break;
/* Thse might be doable with driver-specific queries; dummy for now. */
case D3DQUERYTYPE_BANDWIDTHTIMINGS:
diff --git a/src/gallium/state_trackers/nine/query9.h
b/src/gallium/state_trackers/nine/query9.h
index f08393f..5c34264 100644
--- a/src/gallium/state_trackers/nine/query9.h
+++ b/src/gallium/state_trackers/nine/query9.h
@@ -49,7 +49,7 @@ Nine
[Mesa-dev] [PATCH 09/11] st/nine: Rework queries
From: Axel Davy
From this moment we should handle errors same way as Wine does.
Original patch from John Ettedgui
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/query9.c | 66 +---
1 file changed, 44 insertions(+), 22 deletions(-)
diff --git a/src/gallium/state_trackers/nine/query9.c
b/src/gallium/state_trackers/nine/query9.c
index 908420c..34dfec7 100644
--- a/src/gallium/state_trackers/nine/query9.c
+++ b/src/gallium/state_trackers/nine/query9.c
@@ -123,6 +123,15 @@ NineQuery9_ctor( struct NineQuery9 *This,
if (!This->pq)
return E_OUTOFMEMORY;
} else {
+/* we have a fallback when app create a query that is
+ not supported. Wine has different behaviour. It won't fill the
+ pointer with a valid NineQuery9, but let it NULL and return error.
+ However even if driver doesn't support D3DQUERYTYPE_EVENT, it
+ will say it is supported and have a fallback for it. Since we
+ support more queries than wine we may hit different rendering paths
+ than it, so perhaps these fallbacks are required.
+ TODO: someone with a lot of different games should try to see
+ if these dummy queries are needed. */
DBG("Returning dummy NineQuery9 for %s.\n",
nine_D3DQUERYTYPE_to_str(Type));
}
@@ -174,10 +183,15 @@ NineQuery9_Issue( struct NineQuery9 *This,
DBG("This=%p dwIssueFlags=%d\n", This, dwIssueFlags);
-user_assert((dwIssueFlags == D3DISSUE_BEGIN && !This->instant) ||
+user_assert((dwIssueFlags == D3DISSUE_BEGIN) ||
(dwIssueFlags == 0) ||
(dwIssueFlags == D3DISSUE_END), D3DERR_INVALIDCALL);
+/* Wine tests: always return D3D_OK on D3DISSUE_BEGIN
+ * even when the call is supposed to be forbidden */
+if (dwIssueFlags == D3DISSUE_BEGIN && This->instant)
+return D3D_OK;
+
if (!This->pq) {
DBG("Issued dummy query.\n");
return D3D_OK;
@@ -185,15 +199,17 @@ NineQuery9_Issue( struct NineQuery9 *This,
if (dwIssueFlags == D3DISSUE_BEGIN) {
if (This->state == NINE_QUERY_STATE_RUNNING) {
- pipe->end_query(pipe, This->pq);
- }
+pipe->end_query(pipe, This->pq);
+}
pipe->begin_query(pipe, This->pq);
This->state = NINE_QUERY_STATE_RUNNING;
} else {
-if (This->state == NINE_QUERY_STATE_RUNNING) {
-pipe->end_query(pipe, This->pq);
-This->state = NINE_QUERY_STATE_ENDED;
- }
+if (This->state != NINE_QUERY_STATE_RUNNING &&
+This->type != D3DQUERYTYPE_EVENT &&
+This->type != D3DQUERYTYPE_TIMESTAMP)
+pipe->begin_query(pipe, This->pq);
+pipe->end_query(pipe, This->pq);
+This->state = NINE_QUERY_STATE_ENDED;
}
return D3D_OK;
}
@@ -220,7 +236,7 @@ NineQuery9_GetData( struct NineQuery9 *This,
DWORD dwGetDataFlags )
{
struct pipe_context *pipe = This->base.device->pipe;
-boolean ok = !This->pq;
+boolean ok, should_flush, should_wait;
unsigned i;
union pipe_query_result presult;
union nine_query_result nresult;
@@ -235,22 +251,28 @@ NineQuery9_GetData( struct NineQuery9 *This,
if (!This->pq) {
DBG("No pipe query available.\n");
-if (!dwSize)
- return S_OK;
-}
-if (This->state == NINE_QUERY_STATE_FRESH)
-return S_OK;
+} else {
+should_flush = dwGetDataFlags && This->state !=
NINE_QUERY_STATE_FLUSHED;
+/* Wine tests: D3DQUERYTYPE_TIMESTAMP always succeeds
+ * directly when flushed */
+should_wait = dwGetDataFlags && This->type == D3DQUERYTYPE_TIMESTAMP;
+
+if (This->state == NINE_QUERY_STATE_FRESH) {
+/* App forgot issue the request. Be nice and issue it. */
+(void) NineQuery9_Issue(This, D3DISSUE_END);
+/* Wine tests: we have to succeed. */
+should_flush = TRUE;
+should_wait = TRUE;
+}
-if (!ok) {
-ok = pipe->get_query_result(pipe, This->pq, FALSE, &presult);
-if (!ok) {
-if (dwGetDataFlags) {
-if (This->state != NINE_QUERY_STATE_FLUSHED)
-pipe->flush(pipe, NULL, 0);
-This->state = NINE_QUERY_STATE_FLUSHED;
-}
-return S_FALSE;
+if (should_flush) {
+pipe->flush(pipe, NULL, 0);
+This->state = NINE_QUERY_STATE_FLUSHED;
}
+
+ok = pipe->get_query_result(pipe, This->pq, should_wait, &presult);
+if (!ok)
+return S_FALSE;
}
if (!dwSize)
return S_OK;
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/11] st/nine: call DBG() at more external entry points
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote:
> From: Stanislaw Halik
>
> Cc: "10.4"
> Reviewed-by: David Heidelberg
> Reviewed-by: Axel Davy
> Signed-off-by: Stanislaw Halik
Reviewed-by: Ilia Mirkin
I wouldn't really bother with backporting this to 10.4, but similar
comment as for previous change -- probably fine for this release.
> ---
> src/gallium/state_trackers/nine/basetexture9.c | 17
> src/gallium/state_trackers/nine/cubetexture9.c | 17
> src/gallium/state_trackers/nine/device9.c | 46
> ++
> src/gallium/state_trackers/nine/device9ex.c| 15 +++
> src/gallium/state_trackers/nine/iunknown.c | 2 +
> src/gallium/state_trackers/nine/pixelshader9.c | 4 ++
> src/gallium/state_trackers/nine/query9.c | 7
> src/gallium/state_trackers/nine/resource9.c| 11 ++
> src/gallium/state_trackers/nine/stateblock9.c | 3 ++
> src/gallium/state_trackers/nine/surface9.c | 7
> src/gallium/state_trackers/nine/swapchain9.c | 5 +++
> src/gallium/state_trackers/nine/swapchain9ex.c | 4 ++
> src/gallium/state_trackers/nine/texture9.c | 5 +++
> .../state_trackers/nine/vertexdeclaration9.c | 5 +++
> src/gallium/state_trackers/nine/vertexshader9.c| 3 ++
> src/gallium/state_trackers/nine/volume9.c | 8
> src/gallium/state_trackers/nine/volumetexture9.c | 12 ++
> 17 files changed, 171 insertions(+)
>
> diff --git a/src/gallium/state_trackers/nine/basetexture9.c
> b/src/gallium/state_trackers/nine/basetexture9.c
> index 7bf2f56..12da1e0 100644
> --- a/src/gallium/state_trackers/nine/basetexture9.c
> +++ b/src/gallium/state_trackers/nine/basetexture9.c
> @@ -51,6 +51,9 @@ NineBaseTexture9_ctor( struct NineBaseTexture9 *This,
> (format != D3DFMT_NULL);
> HRESULT hr;
>
> +DBG("This=%p, pParams=%p initResource=%p Type=%d format=%d Pool=%d
> Usage=%d\n",
> +This, pParams, initResource, Type, format, Pool, Usage);
> +
> user_assert(!(Usage & (D3DUSAGE_RENDERTARGET | D3DUSAGE_DEPTHSTENCIL)) ||
> Pool == D3DPOOL_DEFAULT, D3DERR_INVALIDCALL);
> user_assert(!(Usage & D3DUSAGE_DYNAMIC) ||
> @@ -93,6 +96,8 @@ NineBaseTexture9_SetLOD( struct NineBaseTexture9 *This,
> {
> DWORD old = This->lod;
>
> +DBG("This=%p LODNew=%d\n", This, LODNew);
> +
> user_assert(This->base.pool == D3DPOOL_MANAGED, 0);
>
> This->lod = MIN2(LODNew, This->base.info.last_level);
> @@ -106,12 +111,16 @@ NineBaseTexture9_SetLOD( struct NineBaseTexture9 *This,
> DWORD WINAPI
> NineBaseTexture9_GetLOD( struct NineBaseTexture9 *This )
> {
> +DBG("This=%p\n", This);
> +
> return This->lod;
> }
>
> DWORD WINAPI
> NineBaseTexture9_GetLevelCount( struct NineBaseTexture9 *This )
> {
> +DBG("This=%p\n", This);
> +
> if (This->base.usage & D3DUSAGE_AUTOGENMIPMAP)
> return 1;
> return This->base.info.last_level + 1;
> @@ -121,6 +130,8 @@ HRESULT WINAPI
> NineBaseTexture9_SetAutoGenFilterType( struct NineBaseTexture9 *This,
> D3DTEXTUREFILTERTYPE FilterType )
> {
> +DBG("This=%p FilterType=%d\n", This, FilterType);
> +
> if (!(This->base.usage & D3DUSAGE_AUTOGENMIPMAP))
> return D3D_OK;
> user_assert(FilterType != D3DTEXF_NONE, D3DERR_INVALIDCALL);
> @@ -133,6 +144,8 @@ NineBaseTexture9_SetAutoGenFilterType( struct
> NineBaseTexture9 *This,
> D3DTEXTUREFILTERTYPE WINAPI
> NineBaseTexture9_GetAutoGenFilterType( struct NineBaseTexture9 *This )
> {
> +DBG("This=%p\n", This);
> +
> return This->mipfilter;
> }
>
> @@ -433,6 +446,8 @@ NineBaseTexture9_UpdateSamplerView( struct
> NineBaseTexture9 *This,
> struct pipe_sampler_view templ;
> uint8_t swizzle[4];
>
> +DBG("This=%p sRGB=%d\n", This, sRGB);
> +
> if (unlikely(!resource)) {
> if (unlikely(This->format == D3DFMT_NULL))
> return D3D_OK;
> @@ -485,6 +500,8 @@ NineBaseTexture9_UpdateSamplerView( struct
> NineBaseTexture9 *This,
> void WINAPI
> NineBaseTexture9_PreLoad( struct NineBaseTexture9 *This )
> {
> +DBG("This=%p\n", This);
> +
> if (This->dirty && This->base.pool == D3DPOOL_MANAGED)
> NineBaseTexture9_UploadSelf(This);
> }
> diff --git a/src/gallium/state_trackers/nine/cubetexture9.c
> b/src/gallium/state_trackers/nine/cubetexture9.c
> index 5ef09f7..9f5d8e2 100644
> --- a/src/gallium/state_trackers/nine/cubetexture9.c
> +++ b/src/gallium/state_trackers/nine/cubetexture9.c
> @@ -42,6 +42,11 @@ NineCubeTexture9_ctor( struct NineCubeTexture9 *This,
> D3DSURFACE_DESC sfdesc;
> HRESULT hr;
>
> +DBG("This=%p pParams=%p EdgeLength=%u Levels=%u Usage=%d "
> +"Format=%d Pool=%d pSharedHandle=%p\n",
> +This, pParams, EdgeLength, Levels, Usage,
> +Format, Pool, pSharedHandle);
> +
> user_assert(!(Usage & D3DUSAGE_AUTOGENMIPMAP) ||
Re: [Mesa-dev] [PATCH 03/11] st/nine: propertly declare constants
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote: > From: Axel Davy > > Fixes "Error : CONST[20]: Undeclared source register" when running > dx9_alpha_blending_material. Also artifacts on ilo. > > Cc: "10.4" > Tested-by: David Heidelberg > Signed-off-by: Axel Davy > --- > src/gallium/state_trackers/nine/nine_ff.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/state_trackers/nine/nine_ff.c > b/src/gallium/state_trackers/nine/nine_ff.c > index 6890933..f2dbae4 100644 > --- a/src/gallium/state_trackers/nine/nine_ff.c > +++ b/src/gallium/state_trackers/nine/nine_ff.c > @@ -189,10 +189,10 @@ static void nine_ureg_tgsi_dump(struct ureg_program > *ureg, boolean override) > > /* AL should contain base address of lights table. */ > #define LIGHT_CONST(i)\ > -ureg_src_indirect(ureg_src_register(TGSI_FILE_CONSTANT, (i)), _X(AL)) > +ureg_src_indirect(ureg_DECL_constant(ureg, i), _X(AL)) > > #define MATERIAL_CONST(i) \ > -ureg_src_register(TGSI_FILE_CONSTANT, 19 + (i)) > +ureg_DECL_constant(ureg, 19 + (i)) > > #define MISC_CONST(i) \ > ureg_src_register(TGSI_FILE_CONSTANT, (i)) I guess this is how _CONST works, so it's OK, although my personal inclination would have been to declare separately from the uses. I guess the speed difference is pretty minor for all but the largest programs. Does MISC_CONST also need this hack? If not, why not? In any case, this change is Reviewed-by: Ilia Mirkin > -- > 2.1.3 > > ___ > 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] [PATCH 05/11] st/nine: return GetAvailableTextureMem in bytes as expected (v2)
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote:
> PIPE_CAP_VIDEO_MEMORY returns the amount of video memory in megabytes,
> so need to converted it to bytes.
>
> Fixed Warframe memory detection.
>
> v2: also prepare for cards with more than 4GB memory
>
> Cc: "10.4"
> Tested-by: Yaroslav Andrusyak
> Reviewed-by: Axel Davy
> Signed-off-by: David Heidelberg
Reviewed-by: Ilia Mirkin
> ---
> src/gallium/state_trackers/nine/device9.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/nine/device9.c
> b/src/gallium/state_trackers/nine/device9.c
> index 66d5e66..d48f47d 100644
> --- a/src/gallium/state_trackers/nine/device9.c
> +++ b/src/gallium/state_trackers/nine/device9.c
> @@ -423,7 +423,11 @@ NineDevice9_TestCooperativeLevel( struct NineDevice9
> *This )
> UINT WINAPI
> NineDevice9_GetAvailableTextureMem( struct NineDevice9 *This )
> {
> -return This->screen->get_param(This->screen, PIPE_CAP_VIDEO_MEMORY);
> + const unsigned mem = This->screen->get_param(This->screen,
> PIPE_CAP_VIDEO_MEMORY);
> + if (mem < 4096)
> + return mem << 20;
> + else
> + return UINT_MAX;
> }
>
> HRESULT WINAPI
> --
> 2.1.3
>
> ___
> 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] [PATCH 09/11] st/nine: Rework queries
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote:
> From: Axel Davy
>
> From this moment we should handle errors same way as Wine does.
>
> Original patch from John Ettedgui
>
> Cc: "10.4"
> Tested-by: David Heidelberg
> Signed-off-by: Axel Davy
> ---
> src/gallium/state_trackers/nine/query9.c | 66
> +---
> 1 file changed, 44 insertions(+), 22 deletions(-)
>
> diff --git a/src/gallium/state_trackers/nine/query9.c
> b/src/gallium/state_trackers/nine/query9.c
> index 908420c..34dfec7 100644
> --- a/src/gallium/state_trackers/nine/query9.c
> +++ b/src/gallium/state_trackers/nine/query9.c
> @@ -123,6 +123,15 @@ NineQuery9_ctor( struct NineQuery9 *This,
> if (!This->pq)
> return E_OUTOFMEMORY;
> } else {
> +/* we have a fallback when app create a query that is
> + not supported. Wine has different behaviour. It won't fill the
> + pointer with a valid NineQuery9, but let it NULL and return error.
> + However even if driver doesn't support D3DQUERYTYPE_EVENT, it
> + will say it is supported and have a fallback for it. Since we
> + support more queries than wine we may hit different rendering
> paths
> + than it, so perhaps these fallbacks are required.
> + TODO: someone with a lot of different games should try to see
> + if these dummy queries are needed. */
> DBG("Returning dummy NineQuery9 for %s.\n",
> nine_D3DQUERYTYPE_to_str(Type));
> }
> @@ -174,10 +183,15 @@ NineQuery9_Issue( struct NineQuery9 *This,
>
> DBG("This=%p dwIssueFlags=%d\n", This, dwIssueFlags);
>
> -user_assert((dwIssueFlags == D3DISSUE_BEGIN && !This->instant) ||
> +user_assert((dwIssueFlags == D3DISSUE_BEGIN) ||
> (dwIssueFlags == 0) ||
> (dwIssueFlags == D3DISSUE_END), D3DERR_INVALIDCALL);
>
> +/* Wine tests: always return D3D_OK on D3DISSUE_BEGIN
> + * even when the call is supposed to be forbidden */
> +if (dwIssueFlags == D3DISSUE_BEGIN && This->instant)
> +return D3D_OK;
> +
> if (!This->pq) {
> DBG("Issued dummy query.\n");
> return D3D_OK;
> @@ -185,15 +199,17 @@ NineQuery9_Issue( struct NineQuery9 *This,
>
> if (dwIssueFlags == D3DISSUE_BEGIN) {
> if (This->state == NINE_QUERY_STATE_RUNNING) {
> - pipe->end_query(pipe, This->pq);
> - }
> +pipe->end_query(pipe, This->pq);
> +}
> pipe->begin_query(pipe, This->pq);
> This->state = NINE_QUERY_STATE_RUNNING;
> } else {
> -if (This->state == NINE_QUERY_STATE_RUNNING) {
> -pipe->end_query(pipe, This->pq);
> -This->state = NINE_QUERY_STATE_ENDED;
> - }
> +if (This->state != NINE_QUERY_STATE_RUNNING &&
> +This->type != D3DQUERYTYPE_EVENT &&
> +This->type != D3DQUERYTYPE_TIMESTAMP)
> +pipe->begin_query(pipe, This->pq);
> +pipe->end_query(pipe, This->pq);
> +This->state = NINE_QUERY_STATE_ENDED;
> }
> return D3D_OK;
> }
> @@ -220,7 +236,7 @@ NineQuery9_GetData( struct NineQuery9 *This,
> DWORD dwGetDataFlags )
> {
> struct pipe_context *pipe = This->base.device->pipe;
> -boolean ok = !This->pq;
> +boolean ok, should_flush, should_wait;
> unsigned i;
> union pipe_query_result presult;
> union nine_query_result nresult;
> @@ -235,22 +251,28 @@ NineQuery9_GetData( struct NineQuery9 *This,
>
> if (!This->pq) {
> DBG("No pipe query available.\n");
> -if (!dwSize)
> - return S_OK;
> -}
> -if (This->state == NINE_QUERY_STATE_FRESH)
> -return S_OK;
> +} else {
> +should_flush = dwGetDataFlags && This->state !=
> NINE_QUERY_STATE_FLUSHED;
> +/* Wine tests: D3DQUERYTYPE_TIMESTAMP always succeeds
> + * directly when flushed */
> +should_wait = dwGetDataFlags && This->type == D3DQUERYTYPE_TIMESTAMP;
> +
> +if (This->state == NINE_QUERY_STATE_FRESH) {
> +/* App forgot issue the request. Be nice and issue it. */
> +(void) NineQuery9_Issue(This, D3DISSUE_END);
> +/* Wine tests: we have to succeed. */
> +should_flush = TRUE;
> +should_wait = TRUE;
> +}
>
> -if (!ok) {
> -ok = pipe->get_query_result(pipe, This->pq, FALSE, &presult);
> -if (!ok) {
> -if (dwGetDataFlags) {
> -if (This->state != NINE_QUERY_STATE_FLUSHED)
> -pipe->flush(pipe, NULL, 0);
> -This->state = NINE_QUERY_STATE_FLUSHED;
> -}
> -return S_FALSE;
> +if (should_flush) {
> +pipe->flush(pipe, NULL, 0);
> +This->state = NINE_QUERY_STATE_FLUSHED;
This flips the logic around considerably -- instead of flushing on
get_query_result failure, you're flushin
[Mesa-dev] [Bug 83445] eglSwapBuffers() crash on dri
https://bugs.freedesktop.org/show_bug.cgi?id=83445 Tapani Pälli changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tapani Pälli --- was fixed -- 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] [PATCH 10/11] st/nine: Handle queries not supported by the driver
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote:
> From: Axel Davy
>
> Cc: "10.4"
> Signed-off-by: Axel Davy
> ---
> src/gallium/state_trackers/nine/device9.c | 2 +-
> src/gallium/state_trackers/nine/query9.c | 52
> ---
> src/gallium/state_trackers/nine/query9.h | 2 +-
> 3 files changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/state_trackers/nine/device9.c
> b/src/gallium/state_trackers/nine/device9.c
> index d48f47d..f723294 100644
> --- a/src/gallium/state_trackers/nine/device9.c
> +++ b/src/gallium/state_trackers/nine/device9.c
> @@ -3360,7 +3360,7 @@ NineDevice9_CreateQuery( struct NineDevice9 *This,
> DBG("This=%p Type=%d ppQuery=%p\n", This, Type, ppQuery);
>
> if (!ppQuery)
> -return nine_is_query_supported(Type);
> +return nine_is_query_supported(This->screen, Type);
>
> hr = NineQuery9_new(This, &query, Type);
> if (FAILED(hr))
> diff --git a/src/gallium/state_trackers/nine/query9.c
> b/src/gallium/state_trackers/nine/query9.c
> index 34dfec7..f32f572 100644
> --- a/src/gallium/state_trackers/nine/query9.c
> +++ b/src/gallium/state_trackers/nine/query9.c
> @@ -23,16 +23,27 @@
> #include "device9.h"
> #include "query9.h"
> #include "nine_helpers.h"
> +#include "pipe/p_screen.h"
> #include "pipe/p_context.h"
> #include "util/u_math.h"
> +#include "os/os_time.h"
> #include "nine_dump.h"
>
> #define DBG_CHANNEL DBG_QUERY
>
> #define QUERY_TYPE_MAP_CASE(a, b) case D3DQUERYTYPE_##a: return
> PIPE_QUERY_##b
> static inline unsigned
> -d3dquerytype_to_pipe_query(D3DQUERYTYPE type)
> +d3dquerytype_to_pipe_query(struct pipe_screen *screen, D3DQUERYTYPE type)
> {
> +if ((type == D3DQUERYTYPE_OCCLUSION &&
> +!screen->get_param(screen, PIPE_CAP_OCCLUSION_QUERY)) ||
Traditionally this would be indented to 'type' (i.e. to the currently
open '(' ). That makes it easier to read. Perhaps that's what you've
done and gmail is messing it up... but right now this blob of if is
very hard to read. I'd almost recommend doing it as a switch
statement, e.g.
bool available = true;
switch (type) {
case OCCLUSION:
available = screen->get_param(OCCLUSION));
break;
case TIMESTAMP:
case FREQ:
case WHATEVER:
available = screen->get_param(TIMESTAMP);
break;
}
if (!available)
return PIPE_QUERY_TYPES;
IMHO that's _way_ more readable than what you have.
> +((type == D3DQUERYTYPE_TIMESTAMP || type ==
> D3DQUERYTYPE_TIMESTAMPFREQ ||
> +type == D3DQUERYTYPE_TIMESTAMPDISJOINT)&&
> +!screen->get_param(screen, PIPE_CAP_QUERY_TIMESTAMP)) ||
> +(type == D3DQUERYTYPE_VERTEXSTATS &&
> +!screen->get_param(screen, PIPE_CAP_QUERY_PIPELINE_STATISTICS)))
> +return PIPE_QUERY_TYPES;
> +
> switch (type) {
> QUERY_TYPE_MAP_CASE(EVENT, GPU_FINISHED);
> QUERY_TYPE_MAP_CASE(OCCLUSION, OCCLUSION_COUNTER);
> @@ -84,9 +95,9 @@ nine_query_result_size(D3DQUERYTYPE type)
> }
>
> HRESULT
> -nine_is_query_supported(D3DQUERYTYPE type)
> +nine_is_query_supported(struct pipe_screen *screen, D3DQUERYTYPE type)
> {
> -const unsigned ptype = d3dquerytype_to_pipe_query(type);
> +const unsigned ptype = d3dquerytype_to_pipe_query(screen, type);
>
> user_assert(ptype != ~0, D3DERR_INVALIDCALL);
>
> @@ -104,7 +115,7 @@ NineQuery9_ctor( struct NineQuery9 *This,
> D3DQUERYTYPE Type )
> {
> struct pipe_context *pipe = pParams->device->pipe;
> -const unsigned ptype = d3dquerytype_to_pipe_query(Type);
> +const unsigned ptype =
> d3dquerytype_to_pipe_query(pParams->device->screen, Type);
> HRESULT hr;
>
> DBG("This=%p pParams=%p Type=%d\n", This, pParams, Type);
> @@ -282,22 +293,39 @@ NineQuery9_GetData( struct NineQuery9 *This,
> nresult.b = presult.b;
> break;
> case D3DQUERYTYPE_OCCLUSION:
> -nresult.dw = presult.u64;
> +if (This->pq)
> +nresult.dw = presult.u64;
> +else
> +nresult.dw = 0;
> break;
> case D3DQUERYTYPE_TIMESTAMP:
> -nresult.u64 = presult.u64;
> +if (This->pq)
> +nresult.u64 = presult.u64;
> +else
> +nresult.u64 = os_time_get_nano();
> break;
> case D3DQUERYTYPE_TIMESTAMPDISJOINT:
> -nresult.b = presult.timestamp_disjoint.disjoint;
> +if (This->pq)
> +nresult.b = presult.timestamp_disjoint.disjoint;
> +else
> +nresult.b = FALSE;
> break;
> case D3DQUERYTYPE_TIMESTAMPFREQ:
> -nresult.u64 = presult.timestamp_disjoint.frequency;
> +if (This->pq)
> +nresult.u64 = presult.timestamp_disjoint.frequency;
> +else
> +nresult.u64 = 1; /* dummy value */
> break;
> case D3DQUERYTYPE_VERTEXSTATS:
> -nresult.vertexstats.NumRenderedTriangles =
> -presult.pipeline_statistics.c_invocations;
> -nresult.ve
Re: [Mesa-dev] [PATCH 11/11] st/nine: return S_FALSE instead of INVALIDCALL when in building query state
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote:
> From: Axel Davy
>
> It is the same behaviour as wine has.
>
> Cc: "10.4"
> Reviewed-by: David Heidelberg
> Signed-off-by: Axel Davy
> ---
> src/gallium/state_trackers/nine/query9.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/nine/query9.c
> b/src/gallium/state_trackers/nine/query9.c
> index f32f572..c244379 100644
> --- a/src/gallium/state_trackers/nine/query9.c
> +++ b/src/gallium/state_trackers/nine/query9.c
> @@ -255,7 +255,7 @@ NineQuery9_GetData( struct NineQuery9 *This,
> DBG("This=%p pData=%p dwSize=%d dwGetDataFlags=%d\n",
> This, pData, dwSize, dwGetDataFlags);
>
> -user_assert(This->state != NINE_QUERY_STATE_RUNNING, D3DERR_INVALIDCALL);
> +user_assert(This->state != NINE_QUERY_STATE_RUNNING, S_FALSE);
Add a comment about why you're doing this. It's very explicitly
against the d3d9 documentation which says it's supposed to return an
error code when in the "Building" state.
> user_assert(dwSize == 0 || pData, D3DERR_INVALIDCALL);
> user_assert(dwGetDataFlags == 0 ||
> dwGetDataFlags == D3DGETDATA_FLUSH, D3DERR_INVALIDCALL);
> --
> 2.1.3
>
> ___
> 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] [PATCH 16/20] mesa/formats: add new mesa formats and their pack/unpack functions.
On Thu, 2014-11-20 at 13:19 +0100, Samuel Iglesias Gonsálvez wrote: [...] > > + /* Other formats */ > > + MESA_FORMAT_R3G3B2_UNORM, > >/* BBGG GRRR */ > > + MESA_FORMAT_A4B4G4R4_UNORM, /* > > */ > > + MESA_FORMAT_R4G4B4A4_UNORM, /* > > */ > > + MESA_FORMAT_R1G5B5A5_UNORM, /* > > ABBB BBGG GGGR */ > > + MESA_FORMAT_R5G5B5A1_UNORM, /* ABBB > > BBGG GGGR */ > > + MESA_FORMAT_A5B5G5R1_UNORM, /* RGGG > > GGBB BBBA */ > > + MESA_FORMAT_A2B10G10R10_UNORM,/* RRGG > > BBAA */ > > + MESA_FORMAT_A2R10G10B10_UNORM,/* BBGG > > RRAA */ > > + MESA_FORMAT_R2G10B10A10_UNORM,/* AABB > > GGRR */ > > + MESA_FORMAT_A10B10G10R2_UNORM,/* RRGG > > BBAA */ > > > > > > I don't think these formats with 1 or 2 bits for red and more bits for > > alpha actually exist. In the GL spec, it expressly says that 5_5_5_1 > > and 10_10_10_2 are only allowed in combination with GL_RGBA or > > GL_BGRA. The GL_ABGR spec doesn't list any interaction with those > > types, so I would assume that it's not allowed. > > > > There is one glean test that explicitly checks for those combinations > (pixelFormats). What should we do then? Allow them as current code > does? or just remove them? If remove then the test program crashes > because of the assert at the end of _mesa_format_from_format_and_type(), > so we need to do some changes to avoid that. > > I checked what other drivers do in that regard: NVIDIA proprietary driver > allows them and ATI proprietary driver doesn't. > > What do you think? > > Sam I also found that piglit's texture-packed-formats test program uses GL_ABGR_EXT/GL_UNSIGNED_SHORT_5_5_5_1 and GL_ABGR_EXT/GL_UNSIGNED_SHORT_1_5_5_5_REV combinations. Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
