Re: [Mesa-dev] [PATCH] dri/kms: Always zero out struct drm_mode_create_dumb
On Sun, Nov 16, 2014 at 01:37:52AM +, Emil Velikov wrote: > On 13/11/14 18:05, Thierry Reding wrote: > > From: Thierry Reding > > > > The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously > > specified, which has the effect that some kernel drivers do not consider > > the .pitch and .size fields of struct drm_mode_create_dumb outputs only. > > Instead they will use these as lower bounds and overwrite them only if > > the values that they compute are larger than what userspace provided. > > > > This works if and only if userspace initializes the fields explicitly to > > either 0 or some meaningful value. However, if userspace just leaves the > > values uninitialized and the struct drm_mode_create_dumb is allocated on > > the stack for example, the driver may try to overallocate buffers. > > > > Fortunately most userspace does zero out the structure before passing it > > to the IOCTL, but there are rare exceptions. Mesa is one of them. In an > > attempt to rectify this situation, kernel drivers are being updated to > > not use the .pitch and .size fields as inputs. However in order to fix > > the issue with older kernels, make sure that Mesa always zeros out the > > structure as well. > > > > Future IOCTLs should be more rigorously defined so that structures can > > be validated and IOCTLs rejected if output fields aren't set to zero. > > > Thanks Thierry. > > I'm pretty sure the intent here was not to misuse the API, yet again > zeroing the struct sounds like a good idea. I've added Daniel's r-b and > pushed this to master. I didn't mean to imply that there were any such intentions. In fact the API documents that these fields are outputs so it shouldn't be necessary to set them. As such, the Mesa code wasn't doing anything wrong. But it turns out this documentation wasn't sufficient and some drivers used the fields nevertheless. > Do you think it's of any use if we push this for the stable branches ? > I've not checked your drm changes, this I don't know if we actually > check/validate pitch & size. Is the ioctl going to carry on, throw a > warning or just error out ? I don't think this needs to go into stable branches. The only drivers that were using this were ones that are unlikely to be used with Mesa. The only reason I noticed is because I've been working on a patch that lets Nouveau integrate better on Tegra, which has the side-effect of these dumb buffer allocations going through the Tegra DRM driver. The DRM changes happened in two parts: first all drivers that were abusing these fields were changed not to do that anymore. The second change was to zero out these fields in the DRM core before the IOCTL data is passed into drivers so that new drivers won't fall into the same trap. That means even for the rare cases where this is actually relevant new kernels will be able to cope with older Mesa releases. For future IOCTLs the decision was made to better document inputs and outputs as well as require outputs to be zeroed out by userspace so that the kernel can run some sanity checks and refuse an IOCTL with invalid input/output. Thierry pgpxW2UEgGUQZ.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer
Hi Marek, > First of all, sorry for breaking Draw yesterday. No problem. draw_llvm.c was really obfuscating the fact that it relied on the layout of the pipe_viewport_state. > There's also the OpenGL extension AMD_vertex_shader_layer which is > supported by all GS-capable Mesa drivers except for nouveau and > llvmpipe I think. I see. It sounds we should try to support these things from vs then. > tgsi_parse is something else. Did you mean tgsi_text_translate? Yes, I meant tgsi_text_translate. > I > don't like using ureg for helper shaders unless I have to. Shaders > written with ureg are harder to read and the code is longer. I've been > thinking of rewriting all simple shaders to text. I don't think that's a good idea. Besides all the reasons I said before, string constants are not convenient to parameterize. One needs to have multiple versions of the text file, or use snprintf. either way quite ugly. Regarding readability, if one has a comment before the code is just as readable. This is not what's done in u_simple_shaders.c, but we use this approach elsewhere and it works quite nicely: [...] /* DP3 TEMP.w, SRC, SRC */ ureg_DP3(tbi->prog, temp_dst_w, src, src); /* RSQ TEMP.w, TEMP.w */ ureg_RSQ(tbi->prog, temp_dst_w, temp_src_w); [...] If people feel strongly about writing helper TGSI shaders in plain text, then we should create a simple off-line compilation tool that compiles the TGSI and creates *.h files (similar like DirectX HLSL tools). Jose PS: Apologies for quoting only parts of the email. I'm sort of limited to using Outlook Web Access for email when working from home, and need to manually quote... From: Marek Olšák Sent: 16 November 2014 15:51 To: Jose Fonseca Cc: Ilia Mirkin; mesa-dev@lists.freedesktop.org; 10.3 10.4 Subject: Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer Hi Jose, First of all, sorry for breaking Draw yesterday. On Sun, Nov 16, 2014 at 2:57 PM, Jose Fonseca wrote: >> Fun fact -- llvmpipe also needs this. > > I think this is because this functionality was developed with D3D10 in mind, > and > > https://urldefense.proofpoint.com/v2/url?u=http-3A__msdn.microsoft.com_en-2Dgb_library_windows_desktop_bb509647.aspx&d=AAIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=W_WiVknXaiEWMUhwH9NoKnxZ7SZQGp1B1VyLSBhv0rU&s=hwsRL-R8OHz5lpkwIvnmSRlHe-ijQAReKLFMkeVDWHM&e= > > states that SV_RenderTargetArrayIndex "an be written from the geometry shader > and read by the pixel shader." There's also the OpenGL extension AMD_vertex_shader_layer which is supported by all GS-capable Mesa drivers except for nouveau and llvmpipe I think. > > > BTW, coding these helper shaders as text is not a great idea IMO: > > - The tgsi_parse thing was written for debugging purposes mainly. > > - Whenever there are TGSI interface changes, any breakage with ureg will > cause compile errors, where as it will only be detected at runtime with TGSI > > - ureg module makes it really easy to write shaders. It's not really much > more work. tgsi_parse is something else. Did you mean tgsi_text_translate? I don't like using ureg for helper shaders unless I have to. Shaders written with ureg are harder to read and the code is longer. I've been thinking of rewriting all simple shaders to text. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] auxiliary: ship all files in the distribution tarball
> I take that despite that it's still a good idea to keep around if/when one > needs it. Yep. I don't oppose moving it elsewhere (e.g, src/gallium/tools/) if its presence in src/gallium/auxiliary/gallivm is confusing. > Apologies for the breakage, it was definitely not intended to get someone to > look at the commit message. :) No prob. There's a lot of traffic in Mesa nowadays, I easily miss stuff that I'm not explicitly CC'ed. Jose From: Emil Velikov Sent: 16 November 2014 18:35 To: Jose Fonseca; mesa-dev@lists.freedesktop.org Cc: emil.l.veli...@gmail.com Subject: Re: [Mesa-dev] [PATCH 3/4] auxiliary: ship all files in the distribution tarball On 16/11/14 10:07, Jose Fonseca wrote: >> XXX: Should we nuke gallivm/f.cpp ? It seems that no-one is using it. > > No, it's important to keep this file. > > It's not meant to be compiled into mesa. It is meant to be used out of tree > for computing polynomial coefficients as explained in the comments. > > We already had to review the coeffs once to add more precision, and I suspect > we might need to . > I've went through the file and it's history.It seems that it was dormant for ~2years thus my question. I take that despite that it's still a good idea to keep around if/when one needs it. -Emil P.S. Apologies for the breakage, it was definitely not intended to get someone to look at the commit message. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: Avoid deadlock when unloading opengl32.dll
Thanks Emil, makes sense. I totally missed the stable tag. Jose From: Emil Velikov Sent: 16 November 2014 21:12 To: Jose Fonseca; Tom Stellard Cc: emil.l.veli...@gmail.com; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH] llvmpipe: Avoid deadlock when unloading opengl32.dll On 13/11/14 11:10, Jose Fonseca wrote: > Hi Tom, > > That's peculiar. It looks like pthreads got into a weird state somehow. > Don't precisely understand how though. Maybe there's a race inside > pipe_semaphore_signal() with the destruction of the semaphore. > > I think the best thing for now is to revert to old behavior for non-windows > platforms: > Hi Jose, Seems like the patch was missing the mesa-stable tag, unlike the commit that caused the regression. I've went ahead, squashed the two and committed them to 10.3. Please let me know if I've missed anything :) Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer
Well, nvidia hw (pre-GM204; it seems like it's supported there now) doesn't support setting gl_Layer from VS, so it's just not an option there. However I do believe that the HW has enough support to handle color masking as well as scissors, so I might try to add a PIPE_CAP which indicates that pipe->clear can do it all. [First I'd have to double-check that the nvidia hw really can support all this stuff properly.] On the subject of strings -- yeah, parameterizing strings is annoying. When parameters are involved, using ureg_* seems like the better way to go. However for static shaders like this, it'll be hard to beat the readability of a plain string. Either way, I was just copying the way that the existing (gl_Layer-using) vertex shader was implemented. Perhaps the decision of whether to do it one way or another can be arrived at separately from this change? -ilia On Mon, Nov 17, 2014 at 8:20 AM, Jose Fonseca wrote: > Hi Marek, > >> First of all, sorry for breaking Draw yesterday. > > No problem. draw_llvm.c was really obfuscating the fact that it relied on the > layout of the pipe_viewport_state. > >> There's also the OpenGL extension AMD_vertex_shader_layer which is >> supported by all GS-capable Mesa drivers except for nouveau and >> llvmpipe I think. > > I see. It sounds we should try to support these things from vs then. > >> tgsi_parse is something else. Did you mean tgsi_text_translate? > > Yes, I meant tgsi_text_translate. > >> I >> don't like using ureg for helper shaders unless I have to. Shaders >> written with ureg are harder to read and the code is longer. I've been >> thinking of rewriting all simple shaders to text. > > I don't think that's a good idea. > > Besides all the reasons I said before, string constants are not convenient to > parameterize. One needs to have multiple versions of the text file, or use > snprintf. either way quite ugly. > > Regarding readability, if one has a comment before the code is just as > readable. This is not what's done in u_simple_shaders.c, but we use this > approach elsewhere and it works quite nicely: > >[...] > >/* DP3 TEMP.w, SRC, SRC */ >ureg_DP3(tbi->prog, temp_dst_w, src, src); > >/* RSQ TEMP.w, TEMP.w */ >ureg_RSQ(tbi->prog, temp_dst_w, temp_src_w); > >[...] > > > If people feel strongly about writing helper TGSI shaders in plain text, then > we should create a simple off-line compilation tool that compiles the TGSI > and creates *.h files (similar like DirectX HLSL tools). > > > Jose > > PS: Apologies for quoting only parts of the email. I'm sort of limited to > using Outlook Web Access for email when working from home, and need to > manually quote... > > > From: Marek Olšák > Sent: 16 November 2014 15:51 > To: Jose Fonseca > Cc: Ilia Mirkin; mesa-dev@lists.freedesktop.org; 10.3 10.4 > Subject: Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad > when no vs_layer > > Hi Jose, > > First of all, sorry for breaking Draw yesterday. > > On Sun, Nov 16, 2014 at 2:57 PM, Jose Fonseca wrote: >>> Fun fact -- llvmpipe also needs this. >> >> I think this is because this functionality was developed with D3D10 in mind, >> and >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__msdn.microsoft.com_en-2Dgb_library_windows_desktop_bb509647.aspx&d=AAIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=W_WiVknXaiEWMUhwH9NoKnxZ7SZQGp1B1VyLSBhv0rU&s=hwsRL-R8OHz5lpkwIvnmSRlHe-ijQAReKLFMkeVDWHM&e= >> >> states that SV_RenderTargetArrayIndex "an be written from the geometry >> shader and read by the pixel shader." > > There's also the OpenGL extension AMD_vertex_shader_layer which is > supported by all GS-capable Mesa drivers except for nouveau and > llvmpipe I think. > >> >> >> BTW, coding these helper shaders as text is not a great idea IMO: >> >> - The tgsi_parse thing was written for debugging purposes mainly. >> >> - Whenever there are TGSI interface changes, any breakage with ureg will >> cause compile errors, where as it will only be detected at runtime with TGSI >> >> - ureg module makes it really easy to write shaders. It's not really much >> more work. > > tgsi_parse is something else. Did you mean tgsi_text_translate? I > don't like using ureg for helper shaders unless I have to. Shaders > written with ureg are harder to read and the code is longer. I've been > thinking of rewriting all simple shaders to text. > > Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl_compiler: Add binding hash tables to avoid SIGSEVs on linking stage
When using the stand alone compiler, if we try to
link a shader with vertex attributes it will
segfault on linking as the binding hash tables are
not included in the shader program. Obviously, we
cannot make the linking stage succeed without the
bound attributes but we can prevent the crash and
just let the linker spit its own error.
This also adds carriage returns on several linker
errors and fixes a couple of inline comments.
---
src/gallium/auxiliary/draw/draw_private.h | 2 +-
src/gallium/auxiliary/draw/draw_pt_vsplit.c | 2 +-
src/glsl/linker.cpp | 40 ++---
src/glsl/main.cpp | 10
4 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_private.h
b/src/gallium/auxiliary/draw/draw_private.h
index d8dc2ab..37045eb 100644
--- a/src/gallium/auxiliary/draw/draw_private.h
+++ b/src/gallium/auxiliary/draw/draw_private.h
@@ -499,7 +499,7 @@ draw_clamp_viewport_idx(int idx)
/**
* Adds two unsigned integers and if the addition
* overflows then it returns the value from
- * from the overflow_value variable.
+ * the overflow_value variable.
*/
static INLINE unsigned
draw_overflow_uadd(unsigned a, unsigned b,
diff --git a/src/gallium/auxiliary/draw/draw_pt_vsplit.c
b/src/gallium/auxiliary/draw/draw_pt_vsplit.c
index eebcabb..8098ade 100644
--- a/src/gallium/auxiliary/draw/draw_pt_vsplit.c
+++ b/src/gallium/auxiliary/draw/draw_pt_vsplit.c
@@ -91,7 +91,7 @@ vsplit_add_cache(struct vsplit_frontend *vsplit, unsigned
fetch, unsigned ofbias
hash = fetch % MAP_SIZE;
- /* If the value isn't in the cache of it's an overflow due to the
+ /* If the value isn't in the cache or it's an overflow due to the
* element bias */
if (vsplit->cache.fetches[hash] != fetch || ofbias) {
/* update cache */
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 2d31801..794efdc 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -642,7 +642,7 @@ validate_geometry_shader_emissions(struct gl_context *ctx,
emit_vertex.run(prog->_LinkedShaders[MESA_SHADER_GEOMETRY]->ir);
if (emit_vertex.error()) {
linker_error(prog, "Invalid call %s(%d). Accepted values for the "
- "stream parameter are in the range [0, %d].",
+ "stream parameter are in the range [0, %d].\n",
emit_vertex.error_func(),
emit_vertex.error_stream(),
ctx->Const.MaxVertexStreams - 1);
@@ -676,7 +676,7 @@ validate_geometry_shader_emissions(struct gl_context *ctx,
*/
if (prog->Geom.UsesStreams && prog->Geom.OutputType != GL_POINTS) {
linker_error(prog, "EmitStreamVertex(n) and EndStreamPrimitive(n) "
- "with n>0 requires point output");
+ "with n>0 requires point output\n");
}
}
}
@@ -808,7 +808,7 @@ cross_validate_globals(struct gl_shader_program *prog,
linker_error(prog,
"All redeclarations of gl_FragDepth in all "
"fragment shaders in a single program must have "
- "the same set of qualifiers.");
+ "the same set of qualifiers.\n");
}
if (var->data.used && layout_differs) {
@@ -817,7 +817,7 @@ cross_validate_globals(struct gl_shader_program *prog,
"qualifier in any fragment shader, it must be "
"redeclared with the same layout qualifier in "
"all fragment shaders that have assignments to "
- "gl_FragDepth");
+ "gl_FragDepth\n");
}
}
@@ -948,7 +948,7 @@ interstage_cross_validate_uniform_blocks(struct
gl_shader_program *prog)
&sh->UniformBlocks[j]);
if (index == -1) {
- linker_error(prog, "uniform block `%s' has mismatching definitions",
+ linker_error(prog, "uniform block `%s' has mismatching
definitions\n",
sh->UniformBlocks[j].Name);
return false;
}
@@ -1635,7 +1635,7 @@ link_intrastage_shaders(void *mem_ctx,
if ((other_sig != NULL) && other_sig->is_defined
&& !other_sig->is_builtin()) {
- linker_error(prog, "function `%s' is multiply defined",
+ linker_error(prog, "function `%s' is multiply defined\n",
f->name);
return NULL;
}
@@ -2086,7 +2086,7 @@ assign_attribute_or_color_locations(gl_shader_program
*prog,
if (attr + slots > max_index) {
linker_error(prog,
"insufficient contiguous locations "
- "avai
Re: [Mesa-dev] [PATCH 1/4] r600g/compute: Don't leak cbufs in compute state
On Mon, Nov 17, 2014 at 1:45 AM, Michel Dänzer wrote:
> On 14.11.2014 19:37, Marek Olšák wrote:
>> surface_destroy should never be called directly, because surfaces have
>> a reference counter. For unreferencing resources, use
>> pipe_surface_reference(&pointer, NULL). It will call surface_destroy
>> if needed.
>
> Indeed, if this was the right place for this, it could be done both
> easier and more robustly:
>
>for (int i = 0; i < fb_state->nr_cbufs; i++)
>pipe_surface_reference(&fb_state->cbufs[i], NULL);
>
Yeah, you're right about that. After your (Michel/Marek) replies, I
had come to the same conclusion about simplifying things. I'm having
*fun* deciding where the proper place to put this in the evergreen
code is. We end up calling evergreen_set_rat from multiple places,
which is where the surfaces are created, and then we keep a list with
a set count... and the individual surfaces themselves get freed as
their reference counts change. In theory, they all get
referenced/freed at the same point, but there's no guarantees that I
can see.
The first logical place that I saw to put the de-reference is in
evergreen_set_global_binding and the matching
create/delete_compute_state functions.
This seems to only affect evergreen (See the XXX early return comment
in the evergreen set global binding function, which implies someone
knew this was an issue). SI seems to have all the right de-references
in place, but I haven't verified that yet through actual run, just
inspection.
--Aaron
>
>> On Fri, Nov 14, 2014 at 12:43 AM, Aaron Watry wrote:
>>> Walk the array of cbufs backwards and free all of them.
>>>
>>> v3: Rebase on top of changes since Aug 2014
>>>
>>> Signed-off-by: Aaron Watry
>>> ---
>>> src/gallium/drivers/r600/evergreen_compute.c | 9 +
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/r600/evergreen_compute.c
>>> b/src/gallium/drivers/r600/evergreen_compute.c
>>> index 90fdd79..4334743 100644
>>> --- a/src/gallium/drivers/r600/evergreen_compute.c
>>> +++ b/src/gallium/drivers/r600/evergreen_compute.c
>>> @@ -252,6 +252,15 @@ void evergreen_delete_compute_state(struct
>>> pipe_context *ctx, void* state)
>>> if (!shader)
>>> return;
>>>
>>> + if (shader->ctx){
>>> + struct pipe_framebuffer_state *fb_state =
>>> &shader->ctx->framebuffer.state;
>>> + for (int i = fb_state->nr_cbufs - 1; fb_state->nr_cbufs > 0
>>> ; i--){
>>> + shader->ctx->b.b.surface_destroy(ctx,
>>> fb_state->cbufs[i]);
>>> + fb_state->cbufs[i] = NULL;
>>> + fb_state->nr_cbufs--;
>>> + }
>>> + }
>>> +
>>> FREE(shader);
>>> }
>>>
>>> --
>>> 2.1.0
>>>
>>> ___
>>> 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
>>
>
>
> --
> Earthling Michel Dänzer| http://www.amd.com
> Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
>> On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov
>> wrote:
>>> So when checking/building sse code we have three possibilities:
>>> 1 Old compiler, throws an error when using -msse*
>>> 2 New compiler, user disables sse* (-mno-sse*)
>>> 3 New compiler, user doesn't disable sse
>>>
>>> The original code, added code for #1 but not #2. Later on we patched
>>> around the lack of handling #2 by wrapping the code in __SSE4_1__.
>>> Yet it lead to a missing/undefined symbol in case of #1 or #2, which
>>> might cause an issue for #2 when using the i965 driver.
>>>
>>> A bit later we "fixed" the undefined symbol by using #1, rather than
>>> updating it to handle #2. With this commit we set things straight :)
>>>
>>> To top it all up, conventions state that in case of conflicting
>>> (-enable-foo -disable-foo) options, the latter one takes precedence.
>>> Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
>>>
>>> Cc: Siavash Eliasi
>>> Cc: Matt Turner
>>> Signed-off-by: Emil Velikov
>>> ---
>>>
>>> Man this thing is _very_ messy.
>>> Matt from the last hunk it seems that pixman might need fixing. Should
>>> be bother with that, or let people have fun when they hit it :P
>>>
>>> -Emil
>>>
>>> configure.ac | 14 +-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 91e111b..9d1835e 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
>>> dnl
>>> dnl Optional flags, check for compiler support
>>> dnl
>>> -AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
>>> +save_CFLAGS="$CFLAGS"
>>> +CFLAGS="-msse4.1 $CFLAGS"
>>> +AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +int main () {
>>> +__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
>>> +c = _mm_max_epu32(a, b);
>>> +return 0;
>>
>> This seems complicated.
>>
>> (a) Just #include
>> (b) Is any of this even necessary? how about
>>
>> int main() { return !__SSE_4_1__; }
>
> Checking that you can actually using the intrinsics seens like a good
> plan. Pixman's configure.ac has been doing that for a long time. I'd
> rather copy that. It's not like we'd save much by not doing it.
...But then we cannot cross-compile with run-time SSE 4.1 support from
a machine without SSE 4.1 support, no?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/16] glsl: Add ir_binop_pow to get_range
On Mon, 2014-11-17 at 02:51 +0100, Thomas Helland wrote:
> The spec states that pow is undefined for x < 0.
> Just set the range to correspond to a constant 0
> if this is the case.
> ---
> src/glsl/opt_minmax.cpp | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
> index 9852dd9..ad8c88a 100644
> --- a/src/glsl/opt_minmax.cpp
> +++ b/src/glsl/opt_minmax.cpp
> @@ -335,6 +335,17 @@ get_range(ir_rvalue *rval)
> high = add(r0.high, r1.high)->constant_expression_value();
> return minmax_range(low, high);
>
> + case ir_binop_pow:
> + r0 = get_range(expr->operands[0]);
> + if (is_greater_than_or_equal_zero(r0.low))
^^
Hi,
I think that you meant 'less' here.
If not, sorry for the noise.
- Bruno
> +low = new(mem_ctx) ir_constant(0.0f);
> + // Result is undefined so we can set the range to bikeshed.
> + if (is_less_than_zero(r0.high)) {
> +low = new(mem_ctx) ir_constant(0.0f);
> +high = new(mem_ctx) ir_constant(0.0f);
> + }
> + return minmax_range(low, high);
> +
>default:
> break;
>}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On Mon, Nov 17, 2014 at 9:44 AM, Erik Faye-Lund wrote:
> On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
>> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
>>> On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov
>>> wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we "fixed" the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi
Cc: Matt Turner
Signed-off-by: Emil Velikov
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1],
[SSE41_SUPPORTED=0])
+save_CFLAGS="$CFLAGS"
+CFLAGS="-msse4.1 $CFLAGS"
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include
+#include
+#include
+#include
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
>>>
>>> This seems complicated.
>>>
>>> (a) Just #include
>>> (b) Is any of this even necessary? how about
>>>
>>> int main() { return !__SSE_4_1__; }
>>
>> Checking that you can actually using the intrinsics seens like a good
>> plan. Pixman's configure.ac has been doing that for a long time. I'd
>> rather copy that. It's not like we'd save much by not doing it.
>
> ...But then we cannot cross-compile with run-time SSE 4.1 support from
> a machine without SSE 4.1 support, no?
Why not? It's a compile-time test. Obviously if there's no compiler
support, then you're SOL...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On Mon, Nov 17, 2014 at 3:50 PM, Ilia Mirkin wrote:
> On Mon, Nov 17, 2014 at 9:44 AM, Erik Faye-Lund wrote:
>> On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
>>> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov
wrote:
> So when checking/building sse code we have three possibilities:
> 1 Old compiler, throws an error when using -msse*
> 2 New compiler, user disables sse* (-mno-sse*)
> 3 New compiler, user doesn't disable sse
>
> The original code, added code for #1 but not #2. Later on we patched
> around the lack of handling #2 by wrapping the code in __SSE4_1__.
> Yet it lead to a missing/undefined symbol in case of #1 or #2, which
> might cause an issue for #2 when using the i965 driver.
>
> A bit later we "fixed" the undefined symbol by using #1, rather than
> updating it to handle #2. With this commit we set things straight :)
>
> To top it all up, conventions state that in case of conflicting
> (-enable-foo -disable-foo) options, the latter one takes precedence.
> Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
>
> Cc: Siavash Eliasi
> Cc: Matt Turner
> Signed-off-by: Emil Velikov
> ---
>
> Man this thing is _very_ messy.
> Matt from the last hunk it seems that pixman might need fixing. Should
> be bother with that, or let people have fun when they hit it :P
>
> -Emil
>
> configure.ac | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 91e111b..9d1835e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
> dnl
> dnl Optional flags, check for compiler support
> dnl
> -AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1],
> [SSE41_SUPPORTED=0])
> +save_CFLAGS="$CFLAGS"
> +CFLAGS="-msse4.1 $CFLAGS"
> +AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
> +#include
> +#include
> +#include
> +#include
> +int main () {
> +__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
> +c = _mm_max_epu32(a, b);
> +return 0;
This seems complicated.
(a) Just #include
(b) Is any of this even necessary? how about
int main() { return !__SSE_4_1__; }
>>>
>>> Checking that you can actually using the intrinsics seens like a good
>>> plan. Pixman's configure.ac has been doing that for a long time. I'd
>>> rather copy that. It's not like we'd save much by not doing it.
>>
>> ...But then we cannot cross-compile with run-time SSE 4.1 support from
>> a machine without SSE 4.1 support, no?
>
> Why not? It's a compile-time test. Obviously if there's no compiler
> support, then you're SOL...
Right, my bad. Thanks for setting the record straight.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On 17/11/14 14:44, Erik Faye-Lund wrote:
> On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
>> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
>>> On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov
>>> wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we "fixed" the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi
Cc: Matt Turner
Signed-off-by: Emil Velikov
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1],
[SSE41_SUPPORTED=0])
+save_CFLAGS="$CFLAGS"
+CFLAGS="-msse4.1 $CFLAGS"
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include
+#include
+#include
+#include
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
>>>
>>> This seems complicated.
>>>
>>> (a) Just #include
>>> (b) Is any of this even necessary? how about
>>>
>>> int main() { return !__SSE_4_1__; }
>>
>> Checking that you can actually using the intrinsics seens like a good
>> plan. Pixman's configure.ac has been doing that for a long time. I'd
>> rather copy that. It's not like we'd save much by not doing it.
>
> ...But then we cannot cross-compile with run-time SSE 4.1 support from
> a machine without SSE 4.1 support, no?
>
Autohell should be smart enough to use the correct (cross-compilation)
tool-chain while building that code. Must admit that I have not checked
if that is truly the case.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer
On 17/11/14 13:32, Ilia Mirkin wrote: Well, nvidia hw (pre-GM204; it seems like it's supported there now) doesn't support setting gl_Layer from VS, so it's just not an option there. However I do believe that the HW has enough support to handle color masking as well as scissors, so I might try to add a PIPE_CAP which indicates that pipe->clear can do it all. [First I'd have to double-check that the nvidia hw really can support all this stuff properly.] I forgot to say it explicitely, but I meant supporting this on llvmpipe (or more accurately, in draw module.) On the subject of strings -- yeah, parameterizing strings is annoying. When parameters are involved, using ureg_* seems like the better way to go. However for static shaders like this, it'll be hard to beat the readability of a plain string. Either way, I was just copying the way that the existing (gl_Layer-using) vertex shader was implemented. Perhaps the decision of whether to do it one way or another can be arrived at separately from this change? Sure. I don't have any objection this going in as is, as it is consistent with what was done in there already. It was more a remark for future code. Jose -ilia On Mon, Nov 17, 2014 at 8:20 AM, Jose Fonseca wrote: Hi Marek, First of all, sorry for breaking Draw yesterday. No problem. draw_llvm.c was really obfuscating the fact that it relied on the layout of the pipe_viewport_state. There's also the OpenGL extension AMD_vertex_shader_layer which is supported by all GS-capable Mesa drivers except for nouveau and llvmpipe I think. I see. It sounds we should try to support these things from vs then. tgsi_parse is something else. Did you mean tgsi_text_translate? Yes, I meant tgsi_text_translate. I don't like using ureg for helper shaders unless I have to. Shaders written with ureg are harder to read and the code is longer. I've been thinking of rewriting all simple shaders to text. I don't think that's a good idea. Besides all the reasons I said before, string constants are not convenient to parameterize. One needs to have multiple versions of the text file, or use snprintf. either way quite ugly. Regarding readability, if one has a comment before the code is just as readable. This is not what's done in u_simple_shaders.c, but we use this approach elsewhere and it works quite nicely: [...] /* DP3 TEMP.w, SRC, SRC */ ureg_DP3(tbi->prog, temp_dst_w, src, src); /* RSQ TEMP.w, TEMP.w */ ureg_RSQ(tbi->prog, temp_dst_w, temp_src_w); [...] If people feel strongly about writing helper TGSI shaders in plain text, then we should create a simple off-line compilation tool that compiles the TGSI and creates *.h files (similar like DirectX HLSL tools). Jose PS: Apologies for quoting only parts of the email. I'm sort of limited to using Outlook Web Access for email when working from home, and need to manually quote... From: Marek Olšák Sent: 16 November 2014 15:51 To: Jose Fonseca Cc: Ilia Mirkin; mesa-dev@lists.freedesktop.org; 10.3 10.4 Subject: Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer Hi Jose, First of all, sorry for breaking Draw yesterday. On Sun, Nov 16, 2014 at 2:57 PM, Jose Fonseca wrote: Fun fact -- llvmpipe also needs this. I think this is because this functionality was developed with D3D10 in mind, and https://urldefense.proofpoint.com/v2/url?u=http-3A__msdn.microsoft.com_en-2Dgb_library_windows_desktop_bb509647.aspx&d=AAIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=W_WiVknXaiEWMUhwH9NoKnxZ7SZQGp1B1VyLSBhv0rU&s=hwsRL-R8OHz5lpkwIvnmSRlHe-ijQAReKLFMkeVDWHM&e= states that SV_RenderTargetArrayIndex "an be written from the geometry shader and read by the pixel shader." There's also the OpenGL extension AMD_vertex_shader_layer which is supported by all GS-capable Mesa drivers except for nouveau and llvmpipe I think. BTW, coding these helper shaders as text is not a great idea IMO: - The tgsi_parse thing was written for debugging purposes mainly. - Whenever there are TGSI interface changes, any breakage with ureg will cause compile errors, where as it will only be detected at runtime with TGSI - ureg module makes it really easy to write shaders. It's not really much more work. tgsi_parse is something else. Did you mean tgsi_text_translate? I don't like using ureg for helper shaders unless I have to. Shaders written with ureg are harder to read and the code is longer. I've been thinking of rewriting all simple shaders to text. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [10.4] git describe points to 10.2-branchpoint-3617-ga4ffc2a
Hi Sedat, On 15/11/14 12:50, Sedat Dilek wrote: > Cosmetics? Intended? > > $ LC_ALL=C git status > # On branch master > # Your branch is up-to-date with 'origin/master'. > # > nothing to commit, working directory clean > > $ LC_ALL=C git checkout -b 10.4 origin/10.4 > Branch 10.4 set up to track remote branch 10.4 from origin. > Switched to a new branch '10.4' > > $ LC_ALL=C git describe > 10.2-branchpoint-3617-ga4ffc2a > It seems that git describe does not like/honour tags that have not been signed. With the 10.3 and 10.4 branchpoint being such, this leads to the case you've pointed out. IMHO it would be better to avoid removing/force pushing a signed tag, yet I would not object if the majority of devs wishes to go that route. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [10.4] git describe points to 10.2-branchpoint-3617-ga4ffc2a
On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov wrote: > Hi Sedat, > > On 15/11/14 12:50, Sedat Dilek wrote: >> Cosmetics? Intended? >> >> $ LC_ALL=C git status >> # On branch master >> # Your branch is up-to-date with 'origin/master'. >> # >> nothing to commit, working directory clean >> >> $ LC_ALL=C git checkout -b 10.4 origin/10.4 >> Branch 10.4 set up to track remote branch 10.4 from origin. >> Switched to a new branch '10.4' >> >> $ LC_ALL=C git describe >> 10.2-branchpoint-3617-ga4ffc2a >> > It seems that git describe does not like/honour tags that have not been > signed. With the 10.3 and 10.4 branchpoint being such, this leads to the > case you've pointed out. git help describe: --tags Instead of using only the annotated tags, use any tag found in refs/tags namespace. This option enables matching a lightweight (non-annotated) tag. Does "annotated" mean "signed"? $ git describe HEAD 10.2-branchpoint-3007-ge1c5444 $ git describe --tags HEAD 10.3-branchpoint-937-ge1c5444 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] st/va: surface: render subpicture
From: Michael Varga
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/surface.c | 120
1 file changed, 120 insertions(+)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
index 0d0b863..8d4487b 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -32,6 +32,8 @@
#include "util/u_memory.h"
#include "util/u_handle_table.h"
#include "util/u_rect.h"
+#include "util/u_sampler.h"
+#include "util/u_surface.h"
#include "vl/vl_compositor.h"
#include "vl/vl_winsys.h"
@@ -81,6 +83,7 @@ vlVaCreateSurfaces(VADriverContextP ctx, int width, int
height, int format,
surf->templat = templat;
surf->buffer = drv->pipe->create_video_buffer(drv->pipe, &templat);
+ util_dynarray_init(&surf->subpics);
surfaces[i] = handle_table_add(drv->htab, surf);
}
@@ -109,6 +112,7 @@ vlVaDestroySurfaces(VADriverContextP ctx, VASurfaceID
*surface_list, int num_sur
surf->buffer->destroy(surf->buffer);
if(surf->fence)
drv->pipe->screen->fence_reference(drv->pipe->screen, &surf->fence,
NULL);
+ util_dynarray_fini(&surf->subpics);
FREE(surf);
handle_table_remove(drv->htab, surface_list[i]);
}
@@ -143,6 +147,115 @@ vlVaQuerySurfaceError(VADriverContextP ctx, VASurfaceID
render_target, VAStatus
return VA_STATUS_ERROR_UNIMPLEMENTED;
}
+static void
+upload_sampler(struct pipe_context *pipe, struct pipe_sampler_view *dst,
+ const struct pipe_box *dst_box, const void *src, unsigned
src_stride,
+ unsigned src_x, unsigned src_y)
+{
+ struct pipe_transfer *transfer;
+ void *map;
+
+ map = pipe->transfer_map(pipe, dst->texture, 0, PIPE_TRANSFER_WRITE,
+dst_box, &transfer);
+ if (!map)
+ return;
+
+ util_copy_rect(map, dst->texture->format, transfer->stride, 0, 0,
+ dst_box->width, dst_box->height,
+ src, src_stride, src_x, src_y);
+
+ pipe->transfer_unmap(pipe, transfer);
+}
+
+static VAStatus
+vlVaPutSubpictures(vlVaSurface *surf, vlVaDriver *drv,
+ struct pipe_surface *surf_draw, struct u_rect *dirty_area,
+ struct u_rect *src_rect, struct u_rect *dst_rect)
+{
+ vlVaSubpicture *sub;
+ int i;
+
+ if (!(surf->subpics.data || surf->subpics.size))
+ return VA_STATUS_SUCCESS;
+
+ for (i = 0; i < surf->subpics.size/sizeof(vlVaSubpicture *); i++) {
+ struct pipe_blend_state blend;
+ void *blend_state;
+ vlVaBuffer *buf;
+ struct pipe_box box;
+ struct u_rect *s, *d, sr, dr, c;
+ int sw, sh, dw, dh;
+
+ sub = ((vlVaSubpicture **)surf->subpics.data)[i];
+ if (!sub)
+ continue;
+
+ buf = handle_table_get(drv->htab, sub->image->buf);
+ if (!buf)
+ return VA_STATUS_ERROR_INVALID_IMAGE;
+
+ box.x = 0;
+ box.y = 0;
+ box.z = 0;
+ box.width = sub->dst_rect.x1 - sub->dst_rect.x0;
+ box.height = sub->dst_rect.y1 - sub->dst_rect.y0;
+ box.depth = 1;
+
+ s = &sub->src_rect;
+ d = &sub->dst_rect;
+ sw = s->x1 - s->x0;
+ sh = s->y1 - s->y0;
+ dw = d->x1 - d->x0;
+ dh = d->y1 - d->y0;
+ c.x0 = MAX2(d->x0, s->x0);
+ c.y0 = MAX2(d->y0, s->y0);
+ c.x1 = MIN2(d->x0 + dw, src_rect->x1);
+ c.y1 = MIN2(d->y0 + dh, src_rect->y1);
+ sr.x0 = s->x0 + (c.x0 - d->x0)*(sw/(float)dw);
+ sr.y0 = s->y0 + (c.y0 - d->y0)*(sh/(float)dh);
+ sr.x1 = s->x0 + (c.x1 - d->x0)*(sw/(float)dw);
+ sr.y1 = s->y0 + (c.y1 - d->y0)*(sh/(float)dh);
+
+ s = src_rect;
+ d = dst_rect;
+ sw = s->x1 - s->x0;
+ sh = s->y1 - s->y0;
+ dw = d->x1 - d->x0;
+ dh = d->y1 - d->y0;
+ dr.x0 = d->x0 + c.x0*(dw/(float)sw);
+ dr.y0 = d->y0 + c.y0*(dh/(float)sh);
+ dr.x1 = d->x0 + c.x1*(dw/(float)sw);
+ dr.y1 = d->y0 + c.y1*(dh/(float)sh);
+
+ memset(&blend, 0, sizeof(blend));
+ blend.independent_blend_enable = 0;
+ blend.rt[0].blend_enable = 1;
+ blend.rt[0].rgb_src_factor = PIPE_BLENDFACTOR_SRC_ALPHA;
+ blend.rt[0].rgb_dst_factor = PIPE_BLENDFACTOR_INV_SRC_ALPHA;
+ blend.rt[0].alpha_src_factor = PIPE_BLENDFACTOR_ZERO;
+ blend.rt[0].alpha_dst_factor = PIPE_BLENDFACTOR_ZERO;
+ blend.rt[0].rgb_func = PIPE_BLEND_ADD;
+ blend.rt[0].alpha_func = PIPE_BLEND_ADD;
+ blend.rt[0].colormask = PIPE_MASK_RGBA;
+ blend.logicop_enable = 0;
+ blend.logicop_func = PIPE_LOGICOP_CLEAR;
+ blend.dither = 0;
+ blend_state = drv->pipe->create_blend_state(drv->pipe, &blend);
+
+ vl_compositor_clear_layers(&drv->cstate);
+ vl_compositor_set_layer_blend(&drv->cstate, 0, blend_state, false);
+ upload_sampler(drv->pipe, sub->sampler, &box, buf->data,
+ sub->image->pitches[0], 0, 0);
+ vl_compositor_set_rgba_layer(&drv->cstate, &drv->composi
[Mesa-dev] [PATCH 3/4] st/va: subpicture implementation
From: Michael Varga
added BGRA format
create/destroy
set image
associate/deassociate
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/subpicture.c | 160 ++---
src/gallium/state_trackers/va/va_private.h | 12 +++
2 files changed, 159 insertions(+), 13 deletions(-)
diff --git a/src/gallium/state_trackers/va/subpicture.c
b/src/gallium/state_trackers/va/subpicture.c
index b88511e..07b11e8 100644
--- a/src/gallium/state_trackers/va/subpicture.c
+++ b/src/gallium/state_trackers/va/subpicture.c
@@ -26,8 +26,25 @@
*
**/
+#include "util/u_memory.h"
+#include "util/u_handle_table.h"
+#include "util/u_sampler.h"
+
#include "va_private.h"
+static VAImageFormat subpic_formats[] = {
+ {
+ .fourcc = VA_FOURCC_BGRA,
+ .byte_order = VA_LSB_FIRST,
+ .bits_per_pixel = 32,
+ .depth = 32,
+ .red_mask = 0x00fful,
+ .green_mask = 0xff00ul,
+ .blue_mask = 0x00fful,
+ .alpha_mask = 0xff00ul,
+ },
+};
+
VAStatus
vlVaQuerySubpictureFormats(VADriverContextP ctx, VAImageFormat *format_list,
unsigned int *flags, unsigned int *num_formats)
@@ -38,36 +55,74 @@ vlVaQuerySubpictureFormats(VADriverContextP ctx,
VAImageFormat *format_list,
if (!(format_list && flags && num_formats))
return VA_STATUS_ERROR_UNKNOWN;
- *num_formats = 0;
+ *num_formats = sizeof(subpic_formats)/sizeof(VAImageFormat);
+ memcpy(format_list, subpic_formats, sizeof(subpic_formats));
return VA_STATUS_SUCCESS;
}
VAStatus
-vlVaCreateSubpicture(VADriverContextP ctx, VAImageID image, VASubpictureID
*subpicture)
+vlVaCreateSubpicture(VADriverContextP ctx, VAImageID image,
+ VASubpictureID *subpicture)
{
+ vlVaSubpicture *sub;
+ VAImage *img;
+
if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
- return VA_STATUS_ERROR_UNIMPLEMENTED;
+ img = handle_table_get(VL_VA_DRIVER(ctx)->htab, image);
+ if (!img)
+ return VA_STATUS_ERROR_INVALID_IMAGE;
+
+ sub = CALLOC(1, sizeof(*sub));
+ if (!sub)
+ return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+ sub->image = img;
+ *subpicture = handle_table_add(VL_VA_DRIVER(ctx)->htab, sub);
+
+ return VA_STATUS_SUCCESS;
}
VAStatus
vlVaDestroySubpicture(VADriverContextP ctx, VASubpictureID subpicture)
{
+ vlVaSubpicture *sub;
+
if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
- return VA_STATUS_ERROR_UNIMPLEMENTED;
+ sub = handle_table_get(VL_VA_DRIVER(ctx)->htab, subpicture);
+ if (!sub)
+ return VA_STATUS_ERROR_INVALID_SUBPICTURE;
+
+ FREE(sub);
+ handle_table_remove(VL_VA_DRIVER(ctx)->htab, subpicture);
+
+ return VA_STATUS_SUCCESS;
}
VAStatus
vlVaSubpictureImage(VADriverContextP ctx, VASubpictureID subpicture, VAImageID
image)
{
+ vlVaSubpicture *sub;
+ VAImage *img;
+
if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
- return VA_STATUS_ERROR_UNIMPLEMENTED;
+ img = handle_table_get(VL_VA_DRIVER(ctx)->htab, image);
+ if (!img)
+ return VA_STATUS_ERROR_INVALID_IMAGE;
+
+ sub = handle_table_get(VL_VA_DRIVER(ctx)->htab, subpicture);
+ if (!sub)
+ return VA_STATUS_ERROR_INVALID_SUBPICTURE;
+
+ sub->image = img;
+
+ return VA_STATUS_SUCCESS;
}
VAStatus
@@ -90,26 +145,105 @@ vlVaSetSubpictureGlobalAlpha(VADriverContextP ctx,
VASubpictureID subpicture, fl
}
VAStatus
-vlVaAssociateSubpicture(VADriverContextP ctx, VASubpictureID subpicture,
VASurfaceID *target_surfaces,
-int num_surfaces, short src_x, short src_y,
-unsigned short src_width, unsigned short src_height,
-short dest_x, short dest_y,
-unsigned short dest_width,
-unsigned short dest_height,
+vlVaAssociateSubpicture(VADriverContextP ctx, VASubpictureID subpicture,
+VASurfaceID *target_surfaces, int num_surfaces,
+short src_x, short src_y, unsigned short src_width,
+unsigned short src_height, short dest_x, short dest_y,
+unsigned short dest_width, unsigned short dest_height,
unsigned int flags)
{
+ vlVaSubpicture *sub;
+ struct pipe_resource tex_temp, *tex;
+ struct pipe_sampler_view sampler_templ;
+ vlVaDriver *drv;
+ vlVaSurface *surf;
+ int i;
+ struct u_rect src_rect = {src_x, src_x + src_width, src_y, src_y +
src_height};
+ struct u_rect dst_rect = {dest_x, dest_x + dest_width, dest_y, dest_y +
dest_height};
+
if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
+ drv = VL_VA_DRIVER(ctx);
+
+ sub = handle_table_get(drv->htab, subpicture);
+ if (!sub)
+ return VA_STATUS_ERROR_INVALID_SUBPICTURE;
+
+ for (i = 0; i < num_surfaces; i++) {
+ surf = handle_table_get(drv->htab, target_surfaces[i]);
+ if (!surf)
+ return VA_ST
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On 15/11/14 17:44, Ilia Mirkin wrote: > On Sat, Nov 15, 2014 at 6:52 AM, Emil Velikov > wrote: >> On 14 November 2014 19:50, Ilia Mirkin wrote: >>> On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov >>> wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 -> 10.3.99.901 mesa 10.4.0-rc2 -> 10.3.99.902 ... mesa 10.4.0 -> 10.4.0 >>> >>> Something else that occurred to me -- you want to still make a stable >>> 10.3 release, so 10.3.x will come out after 10.3.99.901? Seems >>> confusing... >>> >> Not sure I fully understand what the confusing part it is. Can you elaborate >> ? >> >> Perhaps the following examples should clear any of your confusion: >> >> 10.3 branch: >> 10.3.0 >> 10.3.0.901 (10.3.1-rc1) >> 10.3.0.902 (10.3.1-rc2) // if needed >> 10.3.1 >> 10.3.1.901 (10.3.2-rc1) >> 10.3.1.902 (10.3.2-rc2) // if needed >> ... you get the idea. >> >> At the same time >> >> Master branch: >> 10.3.99 (10.4-dev) > > So you make this release. One might *think* that the latest 10.3.x is > 10.3.99 then. But it's not. Since *after* this release, you'll put out > a 10.3.2, which will have fixes that 10.3.99 doesn't have. I guess one cannot make things idiot proof (no offence meant here), but I believe that most sensible people will notice/know that the software development diverges after a certain stage. That combined with the extremely unusual approach of using 99 as minor, should be more than a clear sign. Not to mention that there will be no release off the master branch - thus there should be nothing to get confused about in the first place. > It makes > for a non-linear version number situation which IMO is rather > confusing. See the development diverges note above. > With the current version numbering scheme that ~every > project uses except X.org, it's very clear what the latest release is > in a particular line. Also, 10.3.99 has no connection to 10.3 at all, It (10.3.99) is based on the same code as 10.3. That seems like a clear enough connection to me. > it is in fact much closer to 10.4. It *may* be closer. > This is why it makes sense to call > it 10.4-rc1 and not 10.3.x. > One can make sense to call it many things, yet that's a matter of personal interpretation (same goes for me). It seems that despite no clear benefit of keeping the old way, mesa is destined to say stranger to the rest of X on this topic. -Emil > -ilia > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On 15/11/14 17:50, Marek Olšák wrote: > I've always found the X.Org versioning scheme unintuitive. This is > actually for the first time after ~5 years of contributing to open > source graphics that I finally understand how the X versioning works. > Granted, I had never been interested in it anyway. > I take we all have our strengths and weaknesses. Must admit that it took me ~5 seconds to get the idea, even without having a comprehensive list, or reading the web page. > If you need to have a web page on x.org that explains it, that alone > is an indication that it's too complicated. > Just because something is documented it does not mean that it's too complicated for the technically educated mind. One can see plenty of examples on the net - "How to rename a file in WindowsXP" :) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 8/8] nine: Implement threadpool
DRI_PRIME setups have different issues due the lack of dma-buf fences
support in the drivers. For DRI3 DRI_PRIME, a race can appear, making
tearings visible, or worse showing older content than expected. Until
dma-buf fences are well supported (and by all drivers), an alternative
is to send the buffers to the server only when rendering has finished.
Since waiting the rendering has finished in the main thread has a
performance impact, this patch uses an additional thread to offload the
wait and the sending of the buffers to the server.
Reviewed-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/Makefile.sources | 2 +
src/gallium/state_trackers/nine/adapter9.h | 1 +
src/gallium/state_trackers/nine/swapchain9.c | 86 +--
src/gallium/state_trackers/nine/swapchain9.h | 7 +
src/gallium/state_trackers/nine/threadpool.c | 183 +++
src/gallium/state_trackers/nine/threadpool.h | 55 +++
src/gallium/targets/d3dadapter9/drm.c| 16 +-
src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 +
8 files changed, 345 insertions(+), 10 deletions(-)
create mode 100644 src/gallium/state_trackers/nine/threadpool.c
create mode 100644 src/gallium/state_trackers/nine/threadpool.h
diff --git a/src/gallium/state_trackers/nine/Makefile.sources
b/src/gallium/state_trackers/nine/Makefile.sources
index b821961..99b623a 100644
--- a/src/gallium/state_trackers/nine/Makefile.sources
+++ b/src/gallium/state_trackers/nine/Makefile.sources
@@ -59,6 +59,8 @@ C_SOURCES := \
swapchain9.h \
texture9.c \
texture9.h \
+ threadpool.c \
+ threadpool.h \
vertexbuffer9.c \
vertexbuffer9.h \
vertexdeclaration9.c \
diff --git a/src/gallium/state_trackers/nine/adapter9.h
b/src/gallium/state_trackers/nine/adapter9.h
index 4db4f3c..df85b2d 100644
--- a/src/gallium/state_trackers/nine/adapter9.h
+++ b/src/gallium/state_trackers/nine/adapter9.h
@@ -38,6 +38,7 @@ struct d3dadapter9_context
BOOL throttling;
int throttling_value;
int vblank_mode;
+BOOL thread_submit;
void (*destroy)( struct d3dadapter9_context *ctx );
};
diff --git a/src/gallium/state_trackers/nine/swapchain9.c
b/src/gallium/state_trackers/nine/swapchain9.c
index ce92a3a8..b6f5ef6 100644
--- a/src/gallium/state_trackers/nine/swapchain9.c
+++ b/src/gallium/state_trackers/nine/swapchain9.c
@@ -33,6 +33,8 @@
#include "hud/hud_context.h"
#include "state_tracker/drm_driver.h"
+#include "threadpool.h"
+
#define DBG_CHANNEL DBG_SWAPCHAIN
#define UNTESTED(n) DBG("UNTESTED point %d. Please tell if it worked\n", n)
@@ -70,6 +72,7 @@ NineSwapChain9_ctor( struct NineSwapChain9 *This,
pPresentationParameters->hDeviceWindow = hFocusWindow;
This->rendering_done = FALSE;
+This->pool = NULL;
return NineSwapChain9_Resize(This, pPresentationParameters, mode);
}
@@ -227,6 +230,21 @@ NineSwapChain9_Resize( struct NineSwapChain9 *This,
desc.Width = pParams->BackBufferWidth;
desc.Height = pParams->BackBufferHeight;
+if (This->pool) {
+_mesa_threadpool_destroy(This->pool);
+This->pool = NULL;
+}
+This->enable_threadpool = This->actx->thread_submit &&
(pParams->SwapEffect != D3DSWAPEFFECT_COPY);
+if (This->enable_threadpool)
+This->pool = _mesa_threadpool_create();
+if (!This->pool)
+This->enable_threadpool = FALSE;
+
+This->tasks = REALLOC(This->tasks,
+ oldBufferCount * sizeof(struct threadpool_task *),
+ newBufferCount * sizeof(struct threadpool_task *));
+memset(This->tasks, 0, newBufferCount * sizeof(struct threadpool_task *));
+
for (i = 0; i < oldBufferCount; i++) {
ID3DPresent_DestroyD3DWindowBuffer(This->present,
This->present_handles[i]);
This->present_handles[i] = NULL;
@@ -444,6 +462,9 @@ NineSwapChain9_dtor( struct NineSwapChain9 *This )
DBG("This=%p\n", This);
+if (This->pool)
+_mesa_threadpool_destroy(This->pool);
+
if (This->buffers) {
for (i = 0; i < This->params.BackBufferCount; i++) {
NineUnknown_Destroy(NineUnknown(This->buffers[i]));
@@ -541,6 +562,40 @@ handle_draw_cursor_and_hud( struct NineSwapChain9 *This,
struct pipe_resource *r
}
}
+struct end_present_struct {
+struct pipe_screen *screen;
+struct pipe_fence_handle *fence_to_wait;
+ID3DPresent *present;
+D3DWindowBuffer *present_handle;
+HWND hDestWindowOverride;
+};
+
+static void work_present(void *data)
+{
+struct end_present_struct *work = data;
+if (work->fence_to_wait) {
+(void) work->screen->fence_finish(work->screen, work->fence_to_wait,
PIPE_TIMEOUT_INFINITE);
+work->screen->fence_reference(work->screen, &(work->fence_to_wait),
NULL);
+}
+ID3DPresent_PresentBuffer(work->present, work->present_handle,
work->hDestWindowOverride, NULL, NULL, NULL,
[Mesa-dev] [PATCH v4 5/8] gallium/auxiliary: add contained and rect checks (v6)
From: Christoph Bumiller
v3: thanks to Brian, improved coding style, also glennk helped spot few
things (unsigned -> int, two constify)
v4: thanks Ilia improved function, dropped u_box_clip_3d
v5: incorporated rest of Gregor proposed changes,clean ups
v6: u_box_clip_2d simplify proposed by Ilia Mirkin
Reviewed-by: Ilia Mirkin
Reviewed-by: Marek Olšák
Signed-off-by: David Heidelberg
---
src/gallium/auxiliary/util/u_box.h | 118
src/gallium/auxiliary/util/u_rect.h | 18 ++
2 files changed, 136 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_box.h
b/src/gallium/auxiliary/util/u_box.h
index 0b28d0f..520a3d5 100644
--- a/src/gallium/auxiliary/util/u_box.h
+++ b/src/gallium/auxiliary/util/u_box.h
@@ -2,6 +2,7 @@
#define UTIL_BOX_INLINES_H
#include "pipe/p_state.h"
+#include "util/u_math.h"
static INLINE
void u_box_1d( unsigned x,
@@ -77,4 +78,121 @@ void u_box_3d( unsigned x,
box->depth = d;
}
+/* Clips @dst to width @w and height @h.
+ * Returns -1 if the resulting box would be empty (then @dst is left
unchanged).
+ * 0 if nothing has been reduced.
+ * 1 if width has been reduced.
+ * 2 if height has been reduced.
+ * 3 if both width and height have been reduced.
+ * Aliasing permitted.
+ */
+static INLINE int
+u_box_clip_2d(struct pipe_box *dst,
+ const struct pipe_box *box, int w, int h)
+{
+ unsigned i;
+ int a[2], b[2], dim[2];
+ int *start, *end;
+ int res = 0;
+
+ if (!box->width || !box->height)
+ return -1;
+ dim[0] = w;
+ dim[1] = h;
+ a[0] = box->x;
+ a[1] = box->y;
+ b[0] = box->x + box->width;
+ b[1] = box->y + box->height;
+
+ for (i = 0; i < 2; ++i) {
+ start = (a[i] <= b[i]) ? &a[i] : &b[i];
+ end = (a[i] <= b[i]) ? &b[i] : &a[i];
+
+ if (*end < 0 || *start >= dim[i])
+ return -1;
+ if (*start < 0) {
+ *start = 0;
+ res |= (1 << i);
+ }
+ if (*end > dim[i]) {
+ *end = dim[i];
+ res |= (1 << i);
+ }
+ }
+
+ if (res) {
+ dst->x = a[0];
+ dst->y = a[1];
+ dst->width = b[0] - a[0];
+ dst->height = b[1] - a[1];
+ }
+ return res;
+}
+
+static INLINE int64_t
+u_box_volume_3d(const struct pipe_box *box)
+{
+ return (int64_t)box->width * box->height * box->depth;
+}
+
+/* Aliasing of @dst permitted. */
+static INLINE void
+u_box_union_2d(struct pipe_box *dst,
+ const struct pipe_box *a, const struct pipe_box *b)
+{
+ dst->x = MIN2(a->x, b->x);
+ dst->y = MIN2(a->y, b->y);
+
+ dst->width = MAX2(a->x + a->width, b->x + b->width) - dst->x;
+ dst->height = MAX2(a->y + a->height, b->y + b->height) - dst->y;
+}
+
+/* Aliasing of @dst permitted. */
+static INLINE void
+u_box_union_3d(struct pipe_box *dst,
+ const struct pipe_box *a, const struct pipe_box *b)
+{
+ dst->x = MIN2(a->x, b->x);
+ dst->y = MIN2(a->y, b->y);
+ dst->z = MIN2(a->z, b->z);
+
+ dst->width = MAX2(a->x + a->width, b->x + b->width) - dst->x;
+ dst->height = MAX2(a->y + a->height, b->y + b->height) - dst->y;
+ dst->depth = MAX2(a->z + a->depth, b->z + b->depth) - dst->z;
+}
+
+static INLINE boolean
+u_box_test_intersection_2d(const struct pipe_box *a,
+ const struct pipe_box *b)
+{
+ unsigned i;
+ int a_l[2], a_r[2], b_l[2], b_r[2];
+
+ a_l[0] = MIN2(a->x, a->x + a->width);
+ a_r[0] = MAX2(a->x, a->x + a->width);
+ a_l[1] = MIN2(a->y, a->y + a->height);
+ a_r[1] = MAX2(a->y, a->y + a->height);
+
+ b_l[0] = MIN2(b->x, b->x + b->width);
+ b_r[0] = MAX2(b->x, b->x + b->width);
+ b_l[1] = MIN2(b->y, b->y + b->height);
+ b_r[1] = MAX2(b->y, b->y + b->height);
+
+ for (i = 0; i < 2; ++i) {
+ if (a_l[i] > b_r[i] || a_r[i] < b_l[i])
+ return FALSE;
+ }
+ return TRUE;
+}
+
+static INLINE void
+u_box_minify_2d(struct pipe_box *dst,
+const struct pipe_box *src, unsigned l)
+{
+ dst->x = src->x >> l;
+ dst->y = src->y >> l;
+ dst->width = MAX2(src->width >> l, 1);
+ dst->height = MAX2(src->height >> l, 1);
+}
+
#endif
diff --git a/src/gallium/auxiliary/util/u_rect.h
b/src/gallium/auxiliary/util/u_rect.h
index dd87f81..cf29dff 100644
--- a/src/gallium/auxiliary/util/u_rect.h
+++ b/src/gallium/auxiliary/util/u_rect.h
@@ -30,6 +30,7 @@
#define U_RECT_H
#include "pipe/p_compiler.h"
+#include "util/u_math.h"
#ifdef __cplusplus
extern "C" {
@@ -67,6 +68,12 @@ u_rect_find_intersection(const struct u_rect *a,
}
+static INLINE int
+u_rect_area(const struct u_rect *r)
+{
+ return (r->x1 - r->x0) * (r->y1 - r->y0);
+}
+
static INLINE void
u_rect_possible_intersection(const struct u_rect *a,
struct u_rect *b)
@@ -79,6 +86,17 @@ u_rect_possible_intersection(const struct u_rect *a,
}
}
+/* Set @d to a rectangle that covers both @a and @b.
+ */
+static INLINE void
+u_rect_union(struct u_rect *d, const struct u_rect *a, const s
[Mesa-dev] [PATCH v4 7/8] nine: Add drirc options (v2)
Implements vblank_mode and throttling, which allows us change default ratio
between framerate and input lag.
Signed-off-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/adapter9.h | 1 +
src/gallium/state_trackers/nine/swapchain9.c| 5
src/gallium/targets/d3dadapter9/drm.c | 35 +
src/mesa/drivers/dri/common/xmlpool/t_options.h | 13 +
4 files changed, 54 insertions(+)
diff --git a/src/gallium/state_trackers/nine/adapter9.h
b/src/gallium/state_trackers/nine/adapter9.h
index c743347..4db4f3c 100644
--- a/src/gallium/state_trackers/nine/adapter9.h
+++ b/src/gallium/state_trackers/nine/adapter9.h
@@ -37,6 +37,7 @@ struct d3dadapter9_context
BOOL linear_framebuffer;
BOOL throttling;
int throttling_value;
+int vblank_mode;
void (*destroy)( struct d3dadapter9_context *ctx );
};
diff --git a/src/gallium/state_trackers/nine/swapchain9.c
b/src/gallium/state_trackers/nine/swapchain9.c
index b6e8125..ce92a3a8 100644
--- a/src/gallium/state_trackers/nine/swapchain9.c
+++ b/src/gallium/state_trackers/nine/swapchain9.c
@@ -164,6 +164,11 @@ NineSwapChain9_Resize( struct NineSwapChain9 *This,
if (This->desired_fences > DRI_SWAP_FENCES_MAX)
This->desired_fences = DRI_SWAP_FENCES_MAX;
+if (This->actx->vblank_mode == 0)
+pParams->PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;
+else if (This->actx->vblank_mode == 3)
+pParams->PresentationInterval = D3DPRESENT_INTERVAL_ONE;
+
if (mode && This->mode) {
*(This->mode) = *mode;
} else if (mode) {
diff --git a/src/gallium/targets/d3dadapter9/drm.c
b/src/gallium/targets/d3dadapter9/drm.c
index d0b72e0..a58e167 100644
--- a/src/gallium/targets/d3dadapter9/drm.c
+++ b/src/gallium/targets/d3dadapter9/drm.c
@@ -36,6 +36,9 @@
#include "d3dadapter/d3dadapter9.h"
#include "d3dadapter/drm.h"
+#include "xmlconfig.h"
+#include "xmlpool.h"
+
#include
#include
#include
@@ -49,6 +52,16 @@
(DWORD)((lo) & 0x) \
))
+const char __driConfigOptionsNine[] =
+DRI_CONF_BEGIN
+DRI_CONF_SECTION_PERFORMANCE
+ DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_1)
+DRI_CONF_SECTION_END
+DRI_CONF_SECTION_NINE
+DRI_CONF_NINE_THROTTLE(-2)
+DRI_CONF_SECTION_END
+DRI_CONF_END;
+
/* Regarding os versions, we should not define our own as that would simply be
* weird. Defaulting to Win2k/XP seems sane considering the origin of D3D9. The
* driver also defaults to being a generic D3D9 driver, which of course only
@@ -229,6 +242,9 @@ drm_create_adapter( int fd,
int i, different_device;
const struct drm_conf_ret *throttle_ret = NULL;
const struct drm_conf_ret *dmabuf_ret = NULL;
+driOptionCache defaultInitOptions;
+driOptionCache userInitOptions;
+int throttling_value_user;
#if !GALLIUM_STATIC_TARGETS
const char *paths[] = {
@@ -289,6 +305,25 @@ drm_create_adapter( int fd,
} else
ctx->base.throttling = FALSE;
+driParseOptionInfo(&defaultInitOptions, __driConfigOptionsNine);
+driParseConfigFiles(&userInitOptions, &defaultInitOptions, 0, "nine");
+if (driCheckOption(&userInitOptions, "throttle_value", DRI_INT)) {
+throttling_value_user = driQueryOptioni(&userInitOptions,
"throttle_value");
+if (throttling_value_user == -1)
+ctx->base.throttling = FALSE;
+else if (throttling_value_user >= 0) {
+ctx->base.throttling = TRUE;
+ctx->base.throttling_value = throttling_value_user;
+}
+}
+
+if (driCheckOption(&userInitOptions, "vblank_mode", DRI_ENUM))
+ctx->base.vblank_mode = driQueryOptioni(&userInitOptions,
"vblank_mode");
+else
+ctx->base.vblank_mode = 1;
+
+driDestroyOptionCache(&userInitOptions);
+driDestroyOptionInfo(&defaultInitOptions);
#if GALLIUM_STATIC_TARGETS
ctx->base.ref = ninesw_create_screen(ctx->base.hal);
diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h
b/src/mesa/drivers/dri/common/xmlpool/t_options.h
index b73a662..e4f6937 100644
--- a/src/mesa/drivers/dri/common/xmlpool/t_options.h
+++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h
@@ -340,3 +340,16 @@ DRI_CONF_SECTION_BEGIN \
DRI_CONF_OPT_BEGIN(device_id, string, def) \
DRI_CONF_DESC(en,gettext("Define the graphic device to use if
possible")) \
DRI_CONF_OPT_END
+
+/**
+ * \brief Gallium-Nine specific configuration options
+ */
+
+#define DRI_CONF_SECTION_NINE \
+DRI_CONF_SECTION_BEGIN \
+DRI_CONF_DESC(en,gettext("Gallium Nine"))
+
+#define DRI_CONF_NINE_THROTTLE(def) \
+DRI_CONF_OPT_BEGIN(throttle_value, int, def) \
+DRI_CONF_DESC(en,gettext("Define the throttling value. -1 for no
throttling, -2 for default (usually 2), 0 for glfinish behaviour")) \
+DRI_CONF_OPT_END
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://l
[Mesa-dev] [PATCH v4 0/8] Gallium Nine
Hi, Here is last (4th) iteration of Gallium Nine patches. We have integrated the new feedback we have got and hope the status of the serie is good enough now for merge. Thanks, Axel Davy Axel Davy (2): nine: Add drirc options (v2) nine: Implement threadpool Christoph Bumiller (5): tgsi/ureg: add ureg_UARL shortcut (v2) winsys/sw/wrapper: implement is_displaytarget_format_supported for swrast gallium/auxiliary: implement sw_probe_wrapped (v2) gallium/auxiliary: add inc and dec alternative with return (v2) gallium/auxiliary: add contained and rect checks (v6) Joakim Sindholt (1): nine: Add state tracker nine for Direct3D9 (v3) configure.ac | 37 + include/D3D9/d3d9.h| 1858 +++ include/D3D9/d3d9caps.h| 387 +++ include/D3D9/d3d9types.h | 1797 ++ include/d3dadapter/d3dadapter9.h | 101 + include/d3dadapter/drm.h | 44 + include/d3dadapter/present.h | 136 + src/gallium/Automake.inc |3 +- src/gallium/Makefile.am|4 + src/gallium/auxiliary/pipe-loader/pipe_loader.h| 11 + src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 23 + .../auxiliary/target-helpers/inline_sw_helper.h| 28 + src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h |1 + src/gallium/auxiliary/util/u_atomic.h | 78 + src/gallium/auxiliary/util/u_box.h | 118 + src/gallium/auxiliary/util/u_rect.h| 18 + src/gallium/state_trackers/nine/Makefile.am| 13 + src/gallium/state_trackers/nine/Makefile.sources | 73 + src/gallium/state_trackers/nine/README | 78 + src/gallium/state_trackers/nine/adapter9.c | 1091 ++ src/gallium/state_trackers/nine/adapter9.h | 139 + .../state_trackers/nine/authenticatedchannel9.c| 78 + .../state_trackers/nine/authenticatedchannel9.h| 65 + src/gallium/state_trackers/nine/basetexture9.c | 504 +++ src/gallium/state_trackers/nine/basetexture9.h | 138 + src/gallium/state_trackers/nine/cryptosession9.c | 115 + src/gallium/state_trackers/nine/cryptosession9.h | 86 + src/gallium/state_trackers/nine/cubetexture9.c | 274 ++ src/gallium/state_trackers/nine/cubetexture9.h | 79 + src/gallium/state_trackers/nine/device9.c | 3458 src/gallium/state_trackers/nine/device9.h | 801 + src/gallium/state_trackers/nine/device9ex.c| 400 +++ src/gallium/state_trackers/nine/device9ex.h| 149 + src/gallium/state_trackers/nine/device9video.c | 62 + src/gallium/state_trackers/nine/device9video.h | 57 + src/gallium/state_trackers/nine/guid.c | 66 + src/gallium/state_trackers/nine/guid.h | 36 + src/gallium/state_trackers/nine/indexbuffer9.c | 218 ++ src/gallium/state_trackers/nine/indexbuffer9.h | 88 + src/gallium/state_trackers/nine/iunknown.c | 126 + src/gallium/state_trackers/nine/iunknown.h | 153 + src/gallium/state_trackers/nine/nine_debug.c | 104 + src/gallium/state_trackers/nine/nine_debug.h | 135 + src/gallium/state_trackers/nine/nine_defines.h | 55 + src/gallium/state_trackers/nine/nine_dump.c| 813 + src/gallium/state_trackers/nine/nine_dump.h| 52 + src/gallium/state_trackers/nine/nine_ff.c | 2257 + src/gallium/state_trackers/nine/nine_ff.h | 32 + src/gallium/state_trackers/nine/nine_helpers.c | 100 + src/gallium/state_trackers/nine/nine_helpers.h | 176 + src/gallium/state_trackers/nine/nine_lock.c| 3319 +++ src/gallium/state_trackers/nine/nine_lock.h| 51 + src/gallium/state_trackers/nine/nine_pdata.h | 45 + src/gallium/state_trackers/nine/nine_pipe.c| 410 +++ src/gallium/state_trackers/nine/nine_pipe.h| 568 src/gallium/state_trackers/nine/nine_quirk.c | 49 + src/gallium/state_trackers/nine/nine_quirk.h | 36 + src/gallium/state_trackers/nine/nine_shader.c | 2959 + src/gallium/state_trackers/nine/nine_shader.h | 142 + src/gallium/state_trackers/nine/nine_state.c | 1489 + src/gallium/state_trackers/nine/nine_state.h | 234 ++ .../state_trackers/nine/nineexoverlayextension.c | 46 + .../state_trackers/nine/nineexoverlayextension.h | 49 + src/gallium/state_trackers/nine/pixelshader9.c | 172 + src/gallium/state_trackers/nine/pixelshader9.h | 82 + src/gallium/state_trackers/nine/query9.c | 358 ++ src/gallium/state_trackers/nine/query9.h | 83 + src/gallium/state_trackers/nine/resource9.c| 230 ++ src/gallium/state_trackers/nine/resource9.h| 107 + src/g
[Mesa-dev] [PATCH v4 4/8] gallium/auxiliary: add inc and dec alternative with return (v2)
From: Christoph Bumiller
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
Signed-off-by: David Heidelberg
---
src/gallium/auxiliary/util/u_atomic.h | 78 +++
1 file changed, 78 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_atomic.h
b/src/gallium/auxiliary/util/u_atomic.h
index 2f2b42b..f177b60 100644
--- a/src/gallium/auxiliary/util/u_atomic.h
+++ b/src/gallium/auxiliary/util/u_atomic.h
@@ -69,6 +69,18 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return __sync_add_and_fetch(v, 1);
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return __sync_sub_and_fetch(v, 1);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return __sync_val_compare_and_swap(v, old, _new);
@@ -116,6 +128,18 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return __sync_add_and_fetch(v, 1);
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return __sync_sub_and_fetch(v, 1);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return __sync_val_compare_and_swap(v, old, _new);
@@ -161,6 +185,18 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return __sync_add_and_fetch(v, 1);
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return __sync_sub_and_fetch(v, 1);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return __sync_val_compare_and_swap(v, old, _new);
@@ -186,6 +222,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
#define p_atomic_dec_zero(_v) ((boolean) --(*(_v)))
#define p_atomic_inc(_v) ((void) (*(_v))++)
#define p_atomic_dec(_v) ((void) (*(_v))--)
+#define p_atomic_inc_return(_v) ((*(_v))++)
+#define p_atomic_dec_return(_v) ((*(_v))--)
#define p_atomic_cmpxchg(_v, old, _new) (*(_v) == old ? *(_v) = (_new) : *(_v))
#endif
@@ -237,6 +275,32 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ int32_t i;
+
+ __asm {
+ mov eax, [v]
+ lock inc dword ptr [eax]
+ mov [i], eax
+ }
+ return i;
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ int32_t i;
+
+ __asm {
+ mov eax, [v]
+ lock dec dword ptr [eax]
+ mov [i], eax
+ }
+ return i;
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
int32_t orig;
@@ -288,6 +352,12 @@ p_atomic_inc(int32_t *v)
_InterlockedIncrement((long *)v);
}
+static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return _InterlockedIncrement((long *)v);
+}
+
static INLINE void
p_atomic_dec(int32_t *v)
{
@@ -295,6 +365,12 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return _InterlockedDecrement((long *)v);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return _InterlockedCompareExchange((long *)v, _new, old);
@@ -329,6 +405,8 @@ p_atomic_dec_zero(int32_t *v)
#define p_atomic_inc(_v) atomic_inc_32((uint32_t *) _v)
#define p_atomic_dec(_v) atomic_dec_32((uint32_t *) _v)
+#define p_atomic_inc_return(_v) atomic_inc_32_nv((uint32_t *) _v)
+#define p_atomic_dec_return(_v) atomic_dec_32_nv((uint32_t *) _v)
#define p_atomic_cmpxchg(_v, _old, _new) \
atomic_cas_32( (uint32_t *) _v, (uint32_t) _old, (uint32_t) _new)
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 1/8] tgsi/ureg: add ureg_UARL shortcut (v2)
From: Christoph Bumiller v2: moved in in same order as in p_shader_tokens (thanks Brian) Reviewed-by: Marek Olšák Signed-off-by: David Heidelberg --- src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h index 7888be8..4ca4f24 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h +++ b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h @@ -201,6 +201,7 @@ OP13_SAMPLE(GATHER4) OP12(SVIEWINFO) OP13(SAMPLE_POS) OP12(SAMPLE_INFO) +OP11(UARL) OP13(UCMP) -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 3/8] gallium/auxiliary: implement sw_probe_wrapped (v2)
From: Christoph Bumiller
Implement pipe_loader_sw_probe_wrapped which allows to use the wrapped
software renderer backend when using the pipe loader.
v2: - remove unneeded ifdef
- use GALLIUM_PIPE_LOADER_WINSYS_LIBS
- check for CALLOC_STRUCT
thanks to Emil Velikov
Signed-off-by: David Heidelberg
---
src/gallium/Automake.inc | 3 ++-
src/gallium/auxiliary/pipe-loader/pipe_loader.h| 11 +++
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 23 ++
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc
index c43f735..9b312b1 100644
--- a/src/gallium/Automake.inc
+++ b/src/gallium/Automake.inc
@@ -58,7 +58,8 @@ GALLIUM_WINSYS_CFLAGS = \
GALLIUM_PIPE_LOADER_WINSYS_LIBS = \
- $(top_builddir)/src/gallium/winsys/sw/null/libws_null.la
+ $(top_builddir)/src/gallium/winsys/sw/null/libws_null.la \
+ $(top_builddir)/src/gallium/winsys/sw/wrapper/libwsw.la
if HAVE_DRISW
GALLIUM_PIPE_LOADER_WINSYS_LIBS += \
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index 6127a6a..9f43f17 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -166,6 +166,17 @@ pipe_loader_sw_probe_null(struct pipe_loader_device
**devs);
int
pipe_loader_sw_probe(struct pipe_loader_device **devs, int ndev);
+/**
+ * Get a software device wrapped atop another device.
+ *
+ * This function is platform-specific.
+ *
+ * \sa pipe_loader_probe
+ */
+boolean
+pipe_loader_sw_probe_wrapped(struct pipe_loader_device **dev,
+ struct pipe_screen *screen);
+
#ifdef HAVE_PIPE_LOADER_DRM
/**
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index b1b1ca6..3d33264 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
@@ -31,6 +31,7 @@
#include "util/u_dl.h"
#include "sw/dri/dri_sw_winsys.h"
#include "sw/null/null_sw_winsys.h"
+#include "sw/wrapper/wrapper_sw_winsys.h"
#ifdef HAVE_PIPE_LOADER_XLIB
/* Explicitly wrap the header to ease build without X11 headers */
#include "sw/xlib/xlib_sw_winsys.h"
@@ -140,6 +141,28 @@ pipe_loader_sw_probe(struct pipe_loader_device **devs, int
ndev)
return i;
}
+boolean
+pipe_loader_sw_probe_wrapped(struct pipe_loader_device **dev,
+ struct pipe_screen *screen)
+{
+ struct pipe_loader_sw_device *sdev = CALLOC_STRUCT(pipe_loader_sw_device);
+
+ if (!sdev)
+ return false;
+
+ sdev->base.type = PIPE_LOADER_DEVICE_SOFTWARE;
+ sdev->base.driver_name = "swrast";
+ sdev->base.ops = &pipe_loader_sw_ops;
+ sdev->ws = wrapper_sw_winsys_wrap_pipe_screen(screen);
+
+ if (!sdev->ws) {
+ FREE(sdev);
+ return false;
+ }
+ *dev = &sdev->base;
+ return true;
+}
+
static void
pipe_loader_sw_release(struct pipe_loader_device **dev)
{
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 2/8] winsys/sw/wrapper: implement is_displaytarget_format_supported for swrast
From: Christoph Bumiller
Signed-off-by: David Heidelberg
---
src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c
b/src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c
index e552ac2..a6bf498 100644
--- a/src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c
+++ b/src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c
@@ -85,6 +85,19 @@ wrapper_sw_displaytarget(struct sw_displaytarget *dt)
static boolean
+wsw_is_dt_format_supported(struct sw_winsys *ws,
+ unsigned tex_usage,
+ enum pipe_format format)
+{
+ struct wrapper_sw_winsys *wsw = wrapper_sw_winsys(ws);
+
+ return wsw->screen->is_format_supported(wsw->screen, format,
+ PIPE_TEXTURE_2D, 0,
+ PIPE_BIND_RENDER_TARGET |
+ PIPE_BIND_DISPLAY_TARGET);
+}
+
+static boolean
wsw_dt_get_stride(struct wrapper_sw_displaytarget *wdt, unsigned *stride)
{
struct pipe_context *pipe = wdt->winsys->pipe;
@@ -276,6 +289,7 @@ wrapper_sw_winsys_wrap_pipe_screen(struct pipe_screen
*screen)
if (!wsw)
goto err;
+ wsw->base.is_displaytarget_format_supported = wsw_is_dt_format_supported;
wsw->base.displaytarget_create = wsw_dt_create;
wsw->base.displaytarget_from_handle = wsw_dt_from_handle;
wsw->base.displaytarget_get_handle = wsw_dt_get_handle;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [10.4] git describe points to 10.2-branchpoint-3617-ga4ffc2a
On 17/11/14 15:34, Ilia Mirkin wrote: > On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov > wrote: >> Hi Sedat, >> >> On 15/11/14 12:50, Sedat Dilek wrote: >>> Cosmetics? Intended? >>> >>> $ LC_ALL=C git status >>> # On branch master >>> # Your branch is up-to-date with 'origin/master'. >>> # >>> nothing to commit, working directory clean >>> >>> $ LC_ALL=C git checkout -b 10.4 origin/10.4 >>> Branch 10.4 set up to track remote branch 10.4 from origin. >>> Switched to a new branch '10.4' >>> >>> $ LC_ALL=C git describe >>> 10.2-branchpoint-3617-ga4ffc2a >>> >> It seems that git describe does not like/honour tags that have not been >> signed. With the 10.3 and 10.4 branchpoint being such, this leads to the >> case you've pointed out. > > git help describe: > >--tags >Instead of using only the annotated tags, use any tag found in >refs/tags namespace. This option enables matching a lightweight >(non-annotated) tag. > > Does "annotated" mean "signed"? > Your guess is as good as mine. > $ git describe HEAD > 10.2-branchpoint-3007-ge1c5444 > $ git describe --tags HEAD > 10.3-branchpoint-937-ge1c5444 > I would assume that you had something based off 10.3 checked out ? $ git describe --tags origin/master 10.4-branchpoint-25-gae4536b -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] st/va: added internal storage for VAImage and BGRA format
From: Michael Varga
When calling vaCreateImage() an internal copy of VAImage is maintained
since the allocation of "image" may not be guaranteed to live long enough.
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/image.c | 70 +++---
src/gallium/state_trackers/va/va_private.h | 4 +-
2 files changed, 48 insertions(+), 26 deletions(-)
diff --git a/src/gallium/state_trackers/va/image.c
b/src/gallium/state_trackers/va/image.c
index a30155e..022240d 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -44,6 +44,7 @@ static const VAImageFormat formats[VL_VA_MAX_IMAGE_FORMATS] =
{VA_FOURCC('Y','V','1','2')},
{VA_FOURCC('Y','U','Y','V')},
{VA_FOURCC('U','Y','V','Y')},
+ {VA_FOURCC('B','G','R','A')}
};
static void
@@ -93,7 +94,9 @@ vlVaQueryImageFormats(VADriverContextP ctx, VAImageFormat
*format_list, int *num
VAStatus
vlVaCreateImage(VADriverContextP ctx, VAImageFormat *format, int width, int
height, VAImage *image)
{
+ VAStatus status;
vlVaDriver *drv;
+ VAImage *img;
int w, h;
if (!ctx)
@@ -104,50 +107,66 @@ vlVaCreateImage(VADriverContextP ctx, VAImageFormat
*format, int width, int heig
drv = VL_VA_DRIVER(ctx);
- image->image_id = handle_table_add(drv->htab, image);
- image->format = *format;
- image->width = width;
- image->height = height;
+ img = CALLOC(1, sizeof(VAImage));
+ if (!img)
+ return VA_STATUS_ERROR_ALLOCATION_FAILED;
+ img->image_id = handle_table_add(drv->htab, img);
+
+ img->format = *format;
+ img->width = width;
+ img->height = height;
w = align(width, 2);
h = align(width, 2);
switch (format->fourcc) {
case VA_FOURCC('N','V','1','2'):
- image->num_planes = 2;
- image->pitches[0] = w;
- image->offsets[0] = 0;
- image->pitches[1] = w;
- image->offsets[1] = w * h;
- image->data_size = w * h * 3 / 2;
+ img->num_planes = 2;
+ img->pitches[0] = w;
+ img->offsets[0] = 0;
+ img->pitches[1] = w;
+ img->offsets[1] = w * h;
+ img->data_size = w * h * 3 / 2;
break;
case VA_FOURCC('I','4','2','0'):
case VA_FOURCC('Y','V','1','2'):
- image->num_planes = 3;
- image->pitches[0] = w;
- image->offsets[0] = 0;
- image->pitches[1] = w / 2;
- image->offsets[1] = w * h;
- image->pitches[2] = w / 2;
- image->offsets[2] = w * h * 5 / 4;
- image->data_size = w * h * 3 / 2;
+ img->num_planes = 3;
+ img->pitches[0] = w;
+ img->offsets[0] = 0;
+ img->pitches[1] = w / 2;
+ img->offsets[1] = w * h;
+ img->pitches[2] = w / 2;
+ img->offsets[2] = w * h * 5 / 4;
+ img->data_size = w * h * 3 / 2;
break;
case VA_FOURCC('U','Y','V','Y'):
case VA_FOURCC('Y','U','Y','V'):
- image->num_planes = 1;
- image->pitches[0] = w * 2;
- image->offsets[0] = 0;
- image->data_size = w * h * 2;
+ img->num_planes = 1;
+ img->pitches[0] = w * 2;
+ img->offsets[0] = 0;
+ img->data_size = w * h * 2;
+ break;
+
+ case VA_FOURCC('B','G','R','A'):
+ img->num_planes = 1;
+ img->pitches[0] = w * 4;
+ img->offsets[0] = 0;
+ img->data_size = w * h * 4;
break;
default:
return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT;
}
- return vlVaCreateBuffer(ctx, 0, VAImageBufferType,
- align(image->data_size, 16),
- 1, NULL, &image->buf);
+ status = vlVaCreateBuffer(ctx, 0, VAImageBufferType,
+ align(img->data_size, 16),
+ 1, NULL, &img->buf);
+ if (status != VA_STATUS_SUCCESS)
+ return status;
+ *image = *img;
+
+ return status;
}
VAStatus
@@ -172,6 +191,7 @@ vlVaDestroyImage(VADriverContextP ctx, VAImageID image)
return VA_STATUS_ERROR_INVALID_IMAGE;
handle_table_remove(VL_VA_DRIVER(ctx)->htab, image);
+ FREE(vaimage);
return vlVaDestroyBuffer(ctx, vaimage->buf);
}
diff --git a/src/gallium/state_trackers/va/va_private.h
b/src/gallium/state_trackers/va/va_private.h
index 7d2fc24..f250f74 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -44,7 +44,7 @@
#define VL_VA_DRIVER(ctx) ((vlVaDriver *)ctx->pDriverData)
#define VL_VA_PSCREEN(ctx) (VL_VA_DRIVER(ctx)->vscreen->pscreen)
-#define VL_VA_MAX_IMAGE_FORMATS 5
+#define VL_VA_MAX_IMAGE_FORMATS 6
static inline enum pipe_video_chroma_format
ChromaToPipe(int format)
@@ -76,6 +76,8 @@ YCbCrToPipe(unsigned format)
return PIPE_FORMAT_YUYV;
case VA_FOURCC('U','Y','V','Y'):
return PIPE_FORMAT_UYVY;
+ case VA_FOURCC('B','G','R','A'):
+ return PIPE_FORMAT_B8G8R8A8_UNORM;
default:
assert(0);
return PIPE_FORMAT_NONE;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] [10.4] git describe points to 10.2-branchpoint-3617-ga4ffc2a
On Mon, Nov 17, 2014 at 11:01 AM, Emil Velikov wrote: > On 17/11/14 15:34, Ilia Mirkin wrote: >> On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov >> wrote: >>> Hi Sedat, >>> >>> On 15/11/14 12:50, Sedat Dilek wrote: Cosmetics? Intended? $ LC_ALL=C git status # On branch master # Your branch is up-to-date with 'origin/master'. # nothing to commit, working directory clean $ LC_ALL=C git checkout -b 10.4 origin/10.4 Branch 10.4 set up to track remote branch 10.4 from origin. Switched to a new branch '10.4' $ LC_ALL=C git describe 10.2-branchpoint-3617-ga4ffc2a >>> It seems that git describe does not like/honour tags that have not been >>> signed. With the 10.3 and 10.4 branchpoint being such, this leads to the >>> case you've pointed out. >> >> git help describe: >> >>--tags >>Instead of using only the annotated tags, use any tag found in >>refs/tags namespace. This option enables matching a lightweight >>(non-annotated) tag. >> >> Does "annotated" mean "signed"? >> > Your guess is as good as mine. > >> $ git describe HEAD >> 10.2-branchpoint-3007-ge1c5444 >> $ git describe --tags HEAD >> 10.3-branchpoint-937-ge1c5444 >> > I would assume that you had something based off 10.3 checked out ? Yes. It even tells you exactly what commit I had checked out :) > > $ git describe --tags origin/master > 10.4-branchpoint-25-gae4536b > > > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 0/8] Gallium Nine
Sorry, patch 4 is too big the mailing list. The entire serie can be found here: https://github.com/iXit/Mesa-3D/commits/for-upstream-5 On 17/11/2014 16:58, Axel Davy wrote : Hi, Here is last (4th) iteration of Gallium Nine patches. We have integrated the new feedback we have got and hope the status of the serie is good enough now for merge. Thanks, Axel Davy Axel Davy (2): nine: Add drirc options (v2) nine: Implement threadpool Christoph Bumiller (5): tgsi/ureg: add ureg_UARL shortcut (v2) winsys/sw/wrapper: implement is_displaytarget_format_supported for swrast gallium/auxiliary: implement sw_probe_wrapped (v2) gallium/auxiliary: add inc and dec alternative with return (v2) gallium/auxiliary: add contained and rect checks (v6) Joakim Sindholt (1): nine: Add state tracker nine for Direct3D9 (v3) configure.ac | 37 + include/D3D9/d3d9.h| 1858 +++ include/D3D9/d3d9caps.h| 387 +++ include/D3D9/d3d9types.h | 1797 ++ include/d3dadapter/d3dadapter9.h | 101 + include/d3dadapter/drm.h | 44 + include/d3dadapter/present.h | 136 + src/gallium/Automake.inc |3 +- src/gallium/Makefile.am|4 + src/gallium/auxiliary/pipe-loader/pipe_loader.h| 11 + src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 23 + .../auxiliary/target-helpers/inline_sw_helper.h| 28 + src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h |1 + src/gallium/auxiliary/util/u_atomic.h | 78 + src/gallium/auxiliary/util/u_box.h | 118 + src/gallium/auxiliary/util/u_rect.h| 18 + src/gallium/state_trackers/nine/Makefile.am| 13 + src/gallium/state_trackers/nine/Makefile.sources | 73 + src/gallium/state_trackers/nine/README | 78 + src/gallium/state_trackers/nine/adapter9.c | 1091 ++ src/gallium/state_trackers/nine/adapter9.h | 139 + .../state_trackers/nine/authenticatedchannel9.c| 78 + .../state_trackers/nine/authenticatedchannel9.h| 65 + src/gallium/state_trackers/nine/basetexture9.c | 504 +++ src/gallium/state_trackers/nine/basetexture9.h | 138 + src/gallium/state_trackers/nine/cryptosession9.c | 115 + src/gallium/state_trackers/nine/cryptosession9.h | 86 + src/gallium/state_trackers/nine/cubetexture9.c | 274 ++ src/gallium/state_trackers/nine/cubetexture9.h | 79 + src/gallium/state_trackers/nine/device9.c | 3458 src/gallium/state_trackers/nine/device9.h | 801 + src/gallium/state_trackers/nine/device9ex.c| 400 +++ src/gallium/state_trackers/nine/device9ex.h| 149 + src/gallium/state_trackers/nine/device9video.c | 62 + src/gallium/state_trackers/nine/device9video.h | 57 + src/gallium/state_trackers/nine/guid.c | 66 + src/gallium/state_trackers/nine/guid.h | 36 + src/gallium/state_trackers/nine/indexbuffer9.c | 218 ++ src/gallium/state_trackers/nine/indexbuffer9.h | 88 + src/gallium/state_trackers/nine/iunknown.c | 126 + src/gallium/state_trackers/nine/iunknown.h | 153 + src/gallium/state_trackers/nine/nine_debug.c | 104 + src/gallium/state_trackers/nine/nine_debug.h | 135 + src/gallium/state_trackers/nine/nine_defines.h | 55 + src/gallium/state_trackers/nine/nine_dump.c| 813 + src/gallium/state_trackers/nine/nine_dump.h| 52 + src/gallium/state_trackers/nine/nine_ff.c | 2257 + src/gallium/state_trackers/nine/nine_ff.h | 32 + src/gallium/state_trackers/nine/nine_helpers.c | 100 + src/gallium/state_trackers/nine/nine_helpers.h | 176 + src/gallium/state_trackers/nine/nine_lock.c| 3319 +++ src/gallium/state_trackers/nine/nine_lock.h| 51 + src/gallium/state_trackers/nine/nine_pdata.h | 45 + src/gallium/state_trackers/nine/nine_pipe.c| 410 +++ src/gallium/state_trackers/nine/nine_pipe.h| 568 src/gallium/state_trackers/nine/nine_quirk.c | 49 + src/gallium/state_trackers/nine/nine_quirk.h | 36 + src/gallium/state_trackers/nine/nine_shader.c | 2959 + src/gallium/state_trackers/nine/nine_shader.h | 142 + src/gallium/state_trackers/nine/nine_state.c | 1489 + src/gallium/state_trackers/nine/nine_state.h | 234 ++ .../state_trackers/nine/nineexoverlayextension.c | 46 + .../state_trackers/nine/nineexoverlayextension.h | 49 + src/gallium/state_trackers/nine/pixelshader9.c | 172 + src/gallium/state_trackers/nine/pixelshader9.h | 82 +
[Mesa-dev] [PATCH 1/4] st/va: added some calls to handle_table_remove()
From: Michael Varga In a few locations handles were being added but not removed. Signed-off-by: Michael Varga --- src/gallium/state_trackers/va/buffer.c | 1 + src/gallium/state_trackers/va/context.c | 1 + src/gallium/state_trackers/va/image.c | 1 + 3 files changed, 3 insertions(+) diff --git a/src/gallium/state_trackers/va/buffer.c b/src/gallium/state_trackers/va/buffer.c index 4023c32..8f9ba44 100644 --- a/src/gallium/state_trackers/va/buffer.c +++ b/src/gallium/state_trackers/va/buffer.c @@ -131,6 +131,7 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID buf_id) FREE(buf->data); FREE(buf); + handle_table_remove(VL_VA_DRIVER(ctx)->htab, buf_id); return VA_STATUS_SUCCESS; } diff --git a/src/gallium/state_trackers/va/context.c b/src/gallium/state_trackers/va/context.c index ae87d3b..a7a55f9 100644 --- a/src/gallium/state_trackers/va/context.c +++ b/src/gallium/state_trackers/va/context.c @@ -212,6 +212,7 @@ vlVaDestroyContext(VADriverContextP ctx, VAContextID context_id) } context->decoder->destroy(context->decoder); FREE(context); + handle_table_remove(drv->htab, context_id); return VA_STATUS_SUCCESS; } diff --git a/src/gallium/state_trackers/va/image.c b/src/gallium/state_trackers/va/image.c index cd4044a..a30155e 100644 --- a/src/gallium/state_trackers/va/image.c +++ b/src/gallium/state_trackers/va/image.c @@ -171,6 +171,7 @@ vlVaDestroyImage(VADriverContextP ctx, VAImageID image) if (!vaimage) return VA_STATUS_ERROR_INVALID_IMAGE; + handle_table_remove(VL_VA_DRIVER(ctx)->htab, image); return vlVaDestroyBuffer(ctx, vaimage->buf); } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/include/pipe: Added interface for atomic counter buffers in pipe
Hi,
I am having difficulty in understanding why you implemented pipe_surface in
st_atom_atomicbuf.c.
On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash
wrote:
> Hi,
>
> On Sunday, November 16, 2014, Ilia Mirkin wrote:
>
>> The direction I went in was by adapting the shader resources interface
>> for this. I believe it will be possible to use for
>> shader_image_load_store as well.
>>
>
> I asked some questions on mailing list about the implementation. I took
> the same path as uniform buffers. But, I realized that it's not efficient
> to do that.
>
>
>> See https://github.com/imirkin/mesa/commits/atomic
>>
>>
> The commits are similar to my previous patch. I was doing atomics similar
> to uniform buffers, Now I was changing cso_context.
>
>
>> I believe that makes a lot more sense than creating a special counter
>> buffer type only to be used for this. pipe_surface has the requisite
>> offset/etc options.
>
>
> I thought of using uniform buffer data structure with certain flags which
> differentiate between atomics, uniforms, index. Like a generic buffer.
>
>
>> I feel like I've mentioned this before when you asked questions, but
>> I'd highly recommend taking my work and improving on it (or at least
>> understanding it). It's at the point where a driver can implement the
>> backend logic, although some of the mesa/st bits are going to be
>> subject to discussion (and need fixing, it messes up the DCE tgsi
>> pass, so I just disabled it).
>>
>> On Thu, Nov 13, 2014 at 12:18 AM, adityaatluri
>> wrote:
>> > ---
>> > src/gallium/include/pipe/p_context.h | 5 +
>> > src/gallium/include/pipe/p_defines.h | 7 ++-
>> > src/gallium/include/pipe/p_state.h | 10 ++
>> > 3 files changed, 21 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> > index af5674f..bf3be31 100644
>> > --- a/src/gallium/include/pipe/p_context.h
>> > +++ b/src/gallium/include/pipe/p_context.h
>> > @@ -44,6 +44,7 @@ struct pipe_blit_info;
>> > struct pipe_box;
>> > struct pipe_clip_state;
>> > struct pipe_constant_buffer;
>> > +struct pipe_counter_buffer;
>> > struct pipe_depth_stencil_alpha_state;
>> > struct pipe_draw_info;
>> > struct pipe_fence_handle;
>> > @@ -201,6 +202,10 @@ struct pipe_context {
>> > uint shader, uint index,
>> > struct pipe_constant_buffer *buf );
>> >
>> > + void (*set_counter_buffer)( struct pipe_context *,
>> > + uint shader, uint index,
>> > + struct pipe_counter_buffer *buf );
>> > +
>> > void (*set_framebuffer_state)( struct pipe_context *,
>> >const struct pipe_framebuffer_state
>> * );
>> >
>> > diff --git a/src/gallium/include/pipe/p_defines.h
>> b/src/gallium/include/pipe/p_defines.h
>> > index 8c4e415..717ab6a 100644
>> > --- a/src/gallium/include/pipe/p_defines.h
>> > +++ b/src/gallium/include/pipe/p_defines.h
>> > @@ -341,6 +341,7 @@ enum pipe_flush_flags {
>> > #define PIPE_BIND_VERTEX_BUFFER(1 << 4) /* set_vertex_buffers
>> */
>> > #define PIPE_BIND_INDEX_BUFFER (1 << 5) /* draw_elements */
>> > #define PIPE_BIND_CONSTANT_BUFFER (1 << 6) /* set_constant_buffer
>> */
>> > +#define PIPE_BIND_COUNTER_BUFFER (1 << 7) /* set_counter_buffer
>> */
>> > #define PIPE_BIND_DISPLAY_TARGET (1 << 8) /* flush_front_buffer
>> */
>> > #define PIPE_BIND_TRANSFER_WRITE (1 << 9) /* transfer_map */
>> > #define PIPE_BIND_TRANSFER_READ(1 << 10) /* transfer_map */
>> > @@ -572,6 +573,8 @@ enum pipe_cap {
>> > PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE = 109,
>> > PIPE_CAP_SAMPLER_VIEW_TARGET = 110,
>> > PIPE_CAP_CLIP_HALFZ = 111,
>> > + PIPE_CAP_USER_COUNTER_BUFFERS = 112,
>> > + PIPE_CAP_COUNTER_BUFFER_OFFSET_ALIGNMENT = 113,
>> > };
>> >
>> > #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
>> > @@ -631,7 +634,9 @@ enum pipe_shader_cap
>> > PIPE_SHADER_CAP_PREFERRED_IR,
>> > PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED,
>> > PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS,
>> > - PIPE_SHADER_CAP_DOUBLES
>> > + PIPE_SHADER_CAP_DOUBLES,
>> > + PIPE_SHADER_CAP_MAX_COUNTER_BUFFER_SIZE,
>> > + PIPE_SHADER_CAP_MAX_COUNTER_BUFFERS
>> > };
>> >
>> > /**
>> > diff --git a/src/gallium/include/pipe/p_state.h
>> b/src/gallium/include/pipe/p_state.h
>> > index 43bc48b..49fae5d 100644
>> > --- a/src/gallium/include/pipe/p_state.h
>> > +++ b/src/gallium/include/pipe/p_state.h
>> > @@ -57,6 +57,7 @@ extern "C" {
>> > #define PIPE_MAX_CLIP_PLANES 8
>> > #define PIPE_MAX_COLOR_BUFS8
>> > #define PIPE_MAX_CONSTANT_BUFFERS 32
>> > +#define PIPE_MAX_COUNTER_BUFFERS 32
>> > #define PIPE_MAX_SAMPLERS 16
>> > #define PIPE_MAX_SHADER_INPUTS32
>> > #define PIPE_MAX_SHADER_OUTPUTS 48 /* 32 GENERICs + POS, PSIZE, FOG,
>> etc. */
>> > @@ -462,6 +463,15 @@ struct pipe_con
Re: [Mesa-dev] [PATCH] glsl_compiler: Add binding hash tables to avoid SIGSEVs on linking stage
Please split up this patch into:
1. gallium comment fixes
2. linker string fixes
3. hash table code changes
-Brian
On 11/17/2014 07:27 AM, Andres Gomez wrote:
When using the stand alone compiler, if we try to
link a shader with vertex attributes it will
segfault on linking as the binding hash tables are
not included in the shader program. Obviously, we
cannot make the linking stage succeed without the
bound attributes but we can prevent the crash and
just let the linker spit its own error.
This also adds carriage returns on several linker
errors and fixes a couple of inline comments.
---
src/gallium/auxiliary/draw/draw_private.h | 2 +-
src/gallium/auxiliary/draw/draw_pt_vsplit.c | 2 +-
src/glsl/linker.cpp | 40 ++---
src/glsl/main.cpp | 10
4 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_private.h
b/src/gallium/auxiliary/draw/draw_private.h
index d8dc2ab..37045eb 100644
--- a/src/gallium/auxiliary/draw/draw_private.h
+++ b/src/gallium/auxiliary/draw/draw_private.h
@@ -499,7 +499,7 @@ draw_clamp_viewport_idx(int idx)
/**
* Adds two unsigned integers and if the addition
* overflows then it returns the value from
- * from the overflow_value variable.
+ * the overflow_value variable.
*/
static INLINE unsigned
draw_overflow_uadd(unsigned a, unsigned b,
diff --git a/src/gallium/auxiliary/draw/draw_pt_vsplit.c
b/src/gallium/auxiliary/draw/draw_pt_vsplit.c
index eebcabb..8098ade 100644
--- a/src/gallium/auxiliary/draw/draw_pt_vsplit.c
+++ b/src/gallium/auxiliary/draw/draw_pt_vsplit.c
@@ -91,7 +91,7 @@ vsplit_add_cache(struct vsplit_frontend *vsplit, unsigned
fetch, unsigned ofbias
hash = fetch % MAP_SIZE;
- /* If the value isn't in the cache of it's an overflow due to the
+ /* If the value isn't in the cache or it's an overflow due to the
* element bias */
if (vsplit->cache.fetches[hash] != fetch || ofbias) {
/* update cache */
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 2d31801..794efdc 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -642,7 +642,7 @@ validate_geometry_shader_emissions(struct gl_context *ctx,
emit_vertex.run(prog->_LinkedShaders[MESA_SHADER_GEOMETRY]->ir);
if (emit_vertex.error()) {
linker_error(prog, "Invalid call %s(%d). Accepted values for the "
- "stream parameter are in the range [0, %d].",
+ "stream parameter are in the range [0, %d].\n",
emit_vertex.error_func(),
emit_vertex.error_stream(),
ctx->Const.MaxVertexStreams - 1);
@@ -676,7 +676,7 @@ validate_geometry_shader_emissions(struct gl_context *ctx,
*/
if (prog->Geom.UsesStreams && prog->Geom.OutputType != GL_POINTS) {
linker_error(prog, "EmitStreamVertex(n) and EndStreamPrimitive(n) "
- "with n>0 requires point output");
+ "with n>0 requires point output\n");
}
}
}
@@ -808,7 +808,7 @@ cross_validate_globals(struct gl_shader_program *prog,
linker_error(prog,
"All redeclarations of gl_FragDepth in all "
"fragment shaders in a single program must have "
- "the same set of qualifiers.");
+ "the same set of qualifiers.\n");
}
if (var->data.used && layout_differs) {
@@ -817,7 +817,7 @@ cross_validate_globals(struct gl_shader_program *prog,
"qualifier in any fragment shader, it must be "
"redeclared with the same layout qualifier in "
"all fragment shaders that have assignments to "
- "gl_FragDepth");
+ "gl_FragDepth\n");
}
}
@@ -948,7 +948,7 @@ interstage_cross_validate_uniform_blocks(struct
gl_shader_program *prog)
&sh->UniformBlocks[j]);
if (index == -1) {
- linker_error(prog, "uniform block `%s' has mismatching definitions",
+ linker_error(prog, "uniform block `%s' has mismatching
definitions\n",
sh->UniformBlocks[j].Name);
return false;
}
@@ -1635,7 +1635,7 @@ link_intrastage_shaders(void *mem_ctx,
if ((other_sig != NULL) && other_sig->is_defined
&& !other_sig->is_builtin()) {
- linker_error(prog, "function `%s' is multiply defined",
+ linker_error(prog, "function `%s' is multiply defined\n",
f->name);
return NULL;
}
@@ -2086,7 +2086,7 @@ assign_attribute_or_color_locations(gl_shader_program
Re: [Mesa-dev] [PATCH] gallium/include/pipe: Added interface for atomic counter buffers in pipe
Because shader resources were already specified as pipe_surfaces (in
the existing, albeit presently unused API). A pipe_surface is a
wrapper around a resource that specifies what "view" of the resource
should be writable, and attaches an optional format to that resource.
Normally pipe_surfaces are used for render targets, but it applies
just as well here. It applies especially well with a view towards
ARB_shader_image_load_store.
It's conceivable to make a totally separate thing for atomic buffers,
but there's no good reason to -- they will have to be handled in
essentially the same way as regular "image" surfaces will for
ARB_shader_image_load_store.
Cheers,
-ilia
On Mon, Nov 17, 2014 at 11:19 AM, Aditya Avinash
wrote:
> Hi,
> I am having difficulty in understanding why you implemented pipe_surface in
> st_atom_atomicbuf.c.
>
> On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash
> wrote:
>>
>> Hi,
>>
>> On Sunday, November 16, 2014, Ilia Mirkin wrote:
>>>
>>> The direction I went in was by adapting the shader resources interface
>>> for this. I believe it will be possible to use for
>>> shader_image_load_store as well.
>>
>>
>> I asked some questions on mailing list about the implementation. I took
>> the same path as uniform buffers. But, I realized that it's not efficient to
>> do that.
>>
>>>
>>> See https://github.com/imirkin/mesa/commits/atomic
>>>
>>
>> The commits are similar to my previous patch. I was doing atomics similar
>> to uniform buffers, Now I was changing cso_context.
>>
>>>
>>> I believe that makes a lot more sense than creating a special counter
>>> buffer type only to be used for this. pipe_surface has the requisite
>>> offset/etc options.
>>
>>
>> I thought of using uniform buffer data structure with certain flags which
>> differentiate between atomics, uniforms, index. Like a generic buffer.
>>
>>>
>>> I feel like I've mentioned this before when you asked questions, but
>>> I'd highly recommend taking my work and improving on it (or at least
>>> understanding it). It's at the point where a driver can implement the
>>> backend logic, although some of the mesa/st bits are going to be
>>> subject to discussion (and need fixing, it messes up the DCE tgsi
>>> pass, so I just disabled it).
>>>
>>> On Thu, Nov 13, 2014 at 12:18 AM, adityaatluri
>>> wrote:
>>> > ---
>>> > src/gallium/include/pipe/p_context.h | 5 +
>>> > src/gallium/include/pipe/p_defines.h | 7 ++-
>>> > src/gallium/include/pipe/p_state.h | 10 ++
>>> > 3 files changed, 21 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/src/gallium/include/pipe/p_context.h
>>> > b/src/gallium/include/pipe/p_context.h
>>> > index af5674f..bf3be31 100644
>>> > --- a/src/gallium/include/pipe/p_context.h
>>> > +++ b/src/gallium/include/pipe/p_context.h
>>> > @@ -44,6 +44,7 @@ struct pipe_blit_info;
>>> > struct pipe_box;
>>> > struct pipe_clip_state;
>>> > struct pipe_constant_buffer;
>>> > +struct pipe_counter_buffer;
>>> > struct pipe_depth_stencil_alpha_state;
>>> > struct pipe_draw_info;
>>> > struct pipe_fence_handle;
>>> > @@ -201,6 +202,10 @@ struct pipe_context {
>>> > uint shader, uint index,
>>> > struct pipe_constant_buffer *buf );
>>> >
>>> > + void (*set_counter_buffer)( struct pipe_context *,
>>> > + uint shader, uint index,
>>> > + struct pipe_counter_buffer *buf );
>>> > +
>>> > void (*set_framebuffer_state)( struct pipe_context *,
>>> >const struct pipe_framebuffer_state
>>> > * );
>>> >
>>> > diff --git a/src/gallium/include/pipe/p_defines.h
>>> > b/src/gallium/include/pipe/p_defines.h
>>> > index 8c4e415..717ab6a 100644
>>> > --- a/src/gallium/include/pipe/p_defines.h
>>> > +++ b/src/gallium/include/pipe/p_defines.h
>>> > @@ -341,6 +341,7 @@ enum pipe_flush_flags {
>>> > #define PIPE_BIND_VERTEX_BUFFER(1 << 4) /* set_vertex_buffers
>>> > */
>>> > #define PIPE_BIND_INDEX_BUFFER (1 << 5) /* draw_elements */
>>> > #define PIPE_BIND_CONSTANT_BUFFER (1 << 6) /* set_constant_buffer
>>> > */
>>> > +#define PIPE_BIND_COUNTER_BUFFER (1 << 7) /* set_counter_buffer
>>> > */
>>> > #define PIPE_BIND_DISPLAY_TARGET (1 << 8) /* flush_front_buffer
>>> > */
>>> > #define PIPE_BIND_TRANSFER_WRITE (1 << 9) /* transfer_map */
>>> > #define PIPE_BIND_TRANSFER_READ(1 << 10) /* transfer_map */
>>> > @@ -572,6 +573,8 @@ enum pipe_cap {
>>> > PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE = 109,
>>> > PIPE_CAP_SAMPLER_VIEW_TARGET = 110,
>>> > PIPE_CAP_CLIP_HALFZ = 111,
>>> > + PIPE_CAP_USER_COUNTER_BUFFERS = 112,
>>> > + PIPE_CAP_COUNTER_BUFFER_OFFSET_ALIGNMENT = 113,
>>> > };
>>> >
>>> > #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
>>> > @@ -631,7 +634,9 @@ enum pipe_shader_cap
>>> > PIPE_SHADER_CAP_PREFERRED_IR,
>>> > PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED,
>>> >
Re: [Mesa-dev] [PATCH v4 1/8] tgsi/ureg: add ureg_UARL shortcut (v2)
Reviewed-by: Ilia Mirkin On Mon, Nov 17, 2014 at 10:58 AM, Axel Davy wrote: > From: Christoph Bumiller > > v2: moved in in same order as in p_shader_tokens (thanks Brian) > > Reviewed-by: Marek Olšák > Signed-off-by: David Heidelberg > --- > src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h > b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h > index 7888be8..4ca4f24 100644 > --- a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h > +++ b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h > @@ -201,6 +201,7 @@ OP13_SAMPLE(GATHER4) > OP12(SVIEWINFO) > OP13(SAMPLE_POS) > OP12(SAMPLE_INFO) > +OP11(UARL) > > OP13(UCMP) > > -- > 2.1.0 > > ___ > 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 v4 4/8] gallium/auxiliary: add inc and dec alternative with return (v2)
On Mon, Nov 17, 2014 at 10:58 AM, Axel Davy wrote:
> From: Christoph Bumiller
>
> At this moment we use only zero or positive values.
>
> v2: Implement it for also for Solaris, MSVC assembly
> and enable for other combinations.
>
> Signed-off-by: David Heidelberg
> ---
> src/gallium/auxiliary/util/u_atomic.h | 78
> +++
> 1 file changed, 78 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_atomic.h
> b/src/gallium/auxiliary/util/u_atomic.h
> index 2f2b42b..f177b60 100644
> --- a/src/gallium/auxiliary/util/u_atomic.h
> +++ b/src/gallium/auxiliary/util/u_atomic.h
> @@ -69,6 +69,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -116,6 +128,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -161,6 +185,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -186,6 +222,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> #define p_atomic_dec_zero(_v) ((boolean) --(*(_v)))
> #define p_atomic_inc(_v) ((void) (*(_v))++)
> #define p_atomic_dec(_v) ((void) (*(_v))--)
> +#define p_atomic_inc_return(_v) ((*(_v))++)
> +#define p_atomic_dec_return(_v) ((*(_v))--)
> #define p_atomic_cmpxchg(_v, old, _new) (*(_v) == old ? *(_v) = (_new) :
> *(_v))
>
> #endif
> @@ -237,6 +275,32 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + int32_t i;
> +
> + __asm {
> + mov eax, [v]
> + lock inc dword ptr [eax]
> + mov [i], eax
> + }
> + return i;
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + int32_t i;
> +
> + __asm {
> + mov eax, [v]
> + lock dec dword ptr [eax]
> + mov [i], eax
> + }
> + return i;
Both of these seem wrong. "mov [i], eax" -- eax contains the address
of the value, not the value itself, which you're trying to return. I'm
actually not 100% sure how to implement this offhand, but there's a
gcc builting primitive for it, so it must be easy. Just reading [eax]
doesn't seem like it'd work since another thread may have already
decremented it by then. I think this needs to be done as a cmpxchg
type of deal...
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> int32_t orig;
> @@ -288,6 +352,12 @@ p_atomic_inc(int32_t *v)
> _InterlockedIncrement((long *)v);
> }
>
> +static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return _InterlockedIncrement((long *)v);
> +}
> +
> static INLINE void
> p_atomic_dec(int32_t *v)
> {
> @@ -295,6 +365,12 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return _InterlockedDecrement((long *)v);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return _InterlockedCompareExchange((long *)v, _new, old);
> @@ -329,6 +405,8 @@ p_atomic_dec_zero(int32_t *v)
>
> #define p_atomic_inc(_v) atomic_inc_32((uint32_t *) _v)
> #define p_atomic_dec(_v) atomic_dec_32((uint32_t *) _v)
> +#define p_atomic_inc_return(_v) atomic_inc_32_nv((uint32_t *) _v)
> +#define p_atomic_dec_return(_v) atomic_dec_32_nv((uint32_t *) _v)
>
> #define p_atomic_cmpxchg(_v, _old, _new) \
> atomic_cas_32( (uint32_t *) _v, (uint32_t) _old, (uint32_t) _new)
> --
> 2.1.0
>
> ___
> 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] st/mesa: add a fallback for clear_with_quad when no vs_layer
Am 17.11.2014 um 16:21 schrieb Jose Fonseca: > > On 17/11/14 13:32, Ilia Mirkin wrote: >> Well, nvidia hw (pre-GM204; it seems like it's supported there now) >> doesn't support setting gl_Layer from VS, so it's just not an option >> there. However I do believe that the HW has enough support to handle >> color masking as well as scissors, so I might try to add a PIPE_CAP >> which indicates that pipe->clear can do it all. [First I'd have to >> double-check that the nvidia hw really can support all this stuff >> properly.] > > I forgot to say it explicitely, but I meant supporting this on llvmpipe > (or more accurately, in draw module.) I am not entirely sure it doesn't just work. At least for layer no draw interaction should be needed, and the corresponding gs or vs output should be used automatically. For viewports, I think this won't quite work without changes, since in draw it is assumed only gs can write this (see draw_current_shader_viewport_index_output / draw_current_shader_uses_viewport_index and it looks like the tgsi shader info writes_viewport_index would also only be set for gs and not vs. Actually for the latter it seems writes_layer would also only be set for gs but it seems it's not actually used...). I might give it a try and see if that makes things working. Roland > >> On the subject of strings -- yeah, parameterizing strings is annoying. >> When parameters are involved, using ureg_* seems like the better way >> to go. However for static shaders like this, it'll be hard to beat the >> readability of a plain string. Either way, I was just copying the way >> that the existing (gl_Layer-using) vertex shader was implemented. >> >> Perhaps the decision of whether to do it one way or another can be >> arrived at separately from this change? > Sure. I don't have any objection this going in as is, as it is > consistent with what was done in there already. It was more a remark > for future code. > > Jose > >> >>-ilia >> >> On Mon, Nov 17, 2014 at 8:20 AM, Jose Fonseca >> wrote: >>> Hi Marek, >>> First of all, sorry for breaking Draw yesterday. >>> No problem. draw_llvm.c was really obfuscating the fact that it >>> relied on the layout of the pipe_viewport_state. >>> There's also the OpenGL extension AMD_vertex_shader_layer which is supported by all GS-capable Mesa drivers except for nouveau and llvmpipe I think. >>> I see. It sounds we should try to support these things from vs then. >>> tgsi_parse is something else. Did you mean tgsi_text_translate? >>> Yes, I meant tgsi_text_translate. >>> I don't like using ureg for helper shaders unless I have to. Shaders written with ureg are harder to read and the code is longer. I've been thinking of rewriting all simple shaders to text. >>> I don't think that's a good idea. >>> >>> Besides all the reasons I said before, string constants are not >>> convenient to parameterize. One needs to have multiple versions of >>> the text file, or use snprintf. either way quite ugly. >>> >>> Regarding readability, if one has a comment before the code is just >>> as readable. This is not what's done in u_simple_shaders.c, but we >>> use this approach elsewhere and it works quite nicely: >>> >>> [...] >>> >>> /* DP3 TEMP.w, SRC, SRC */ >>> ureg_DP3(tbi->prog, temp_dst_w, src, src); >>> >>> /* RSQ TEMP.w, TEMP.w */ >>> ureg_RSQ(tbi->prog, temp_dst_w, temp_src_w); >>> >>> [...] >>> >>> >>> If people feel strongly about writing helper TGSI shaders in plain >>> text, then we should create a simple off-line compilation tool that >>> compiles the TGSI and creates *.h files (similar like DirectX HLSL >>> tools). >>> >>> >>> Jose >>> >>> PS: Apologies for quoting only parts of the email. I'm sort of >>> limited to using Outlook Web Access for email when working from home, >>> and need to manually quote... >>> >>> >>> From: Marek Olšák >>> Sent: 16 November 2014 15:51 >>> To: Jose Fonseca >>> Cc: Ilia Mirkin; mesa-dev@lists.freedesktop.org; 10.3 10.4 >>> Subject: Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for >>> clear_with_quad when no vs_layer >>> >>> Hi Jose, >>> >>> First of all, sorry for breaking Draw yesterday. >>> >>> On Sun, Nov 16, 2014 at 2:57 PM, Jose Fonseca >>> wrote: > Fun fact -- llvmpipe also needs this. I think this is because this functionality was developed with D3D10 in mind, and https://urldefense.proofpoint.com/v2/url?u=http-3A__msdn.microsoft.com_en-2Dgb_library_windows_desktop_bb509647.aspx&d=AAIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=W_WiVknXaiEWMUhwH9NoKnxZ7SZQGp1B1VyLSBhv0rU&s=hwsRL-R8OHz5lpkwIvnmSRlHe-ijQAReKLFMkeVDWHM&e= states that SV_RenderTargetArrayIndex "an be written from the geometry shader and read by the pixel shader." >>> There's also the OpenGL extension AMD_vertex_shader_layer which is >>> supported by all GS-
Re: [Mesa-dev] [10.4] git describe points to 10.2-branchpoint-3617-ga4ffc2a
On Mon, 2014-11-17 at 16:01 +, Emil Velikov wrote: > On 17/11/14 15:34, Ilia Mirkin wrote: > > On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov > > wrote: > >> Hi Sedat, > >> > >> On 15/11/14 12:50, Sedat Dilek wrote: > >>> Cosmetics? Intended? > >>> > >>> $ LC_ALL=C git status > >>> # On branch master > >>> # Your branch is up-to-date with 'origin/master'. > >>> # > >>> nothing to commit, working directory clean > >>> > >>> $ LC_ALL=C git checkout -b 10.4 origin/10.4 > >>> Branch 10.4 set up to track remote branch 10.4 from origin. > >>> Switched to a new branch '10.4' > >>> > >>> $ LC_ALL=C git describe > >>> 10.2-branchpoint-3617-ga4ffc2a > >>> > >> It seems that git describe does not like/honour tags that have not been > >> signed. With the 10.3 and 10.4 branchpoint being such, this leads to the > >> case you've pointed out. > > > > git help describe: > > > >--tags > >Instead of using only the annotated tags, use any tag found in > >refs/tags namespace. This option enables matching a lightweight > >(non-annotated) tag. > > > > Does "annotated" mean "signed"? > > > Your guess is as good as mine. thought this might help: "Annotated tags, however, are stored as full objects in the Git database. They’re checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). It’s generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don’t want to keep the other information, lightweight tags are available too." git tag -a creates annotated tag > > > $ git describe HEAD > > 10.2-branchpoint-3007-ge1c5444 > > $ git describe --tags HEAD > > 10.3-branchpoint-937-ge1c5444 > > > I would assume that you had something based off 10.3 checked out ? > > $ git describe --tags origin/master > 10.4-branchpoint-25-gae4536b > > > -Emil > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Jan Vesely 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
[Mesa-dev] [PATCH] gallium/tests: add missing arg to util_make_vertex_passthrough_shader()
Fix oversights from the "add a window_space option to the passthrough
vertex shader" patch.
---
src/gallium/tests/trivial/quad-tex.c |2 +-
src/gallium/tests/trivial/tri.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/tests/trivial/quad-tex.c
b/src/gallium/tests/trivial/quad-tex.c
index c09e09a..0d38012 100644
--- a/src/gallium/tests/trivial/quad-tex.c
+++ b/src/gallium/tests/trivial/quad-tex.c
@@ -266,7 +266,7 @@ static void init_prog(struct program *p)
const uint semantic_names[] = { TGSI_SEMANTIC_POSITION,
TGSI_SEMANTIC_GENERIC };
const uint semantic_indexes[] = { 0, 0 };
- p->vs = util_make_vertex_passthrough_shader(p->pipe, 2,
semantic_names, semantic_indexes);
+ p->vs = util_make_vertex_passthrough_shader(p->pipe, 2,
semantic_names, semantic_indexes, FALSE);
}
/* fragment shader */
diff --git a/src/gallium/tests/trivial/tri.c b/src/gallium/tests/trivial/tri.c
index dcc5a22..13cc801 100644
--- a/src/gallium/tests/trivial/tri.c
+++ b/src/gallium/tests/trivial/tri.c
@@ -211,7 +211,7 @@ static void init_prog(struct program *p)
const uint semantic_names[] = { TGSI_SEMANTIC_POSITION,
TGSI_SEMANTIC_COLOR };
const uint semantic_indexes[] = { 0, 0 };
- p->vs = util_make_vertex_passthrough_shader(p->pipe, 2,
semantic_names, semantic_indexes);
+ p->vs = util_make_vertex_passthrough_shader(p->pipe, 2,
semantic_names, semantic_indexes, FALSE);
}
/* fragment shader */
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/tests: add missing arg to util_make_vertex_passthrough_shader()
Reviewed-by: Jakob Bornecrantz
On 17 Nov 2014 18:11, "Brian Paul" wrote:
> Fix oversights from the "add a window_space option to the passthrough
> vertex shader" patch.
> ---
> src/gallium/tests/trivial/quad-tex.c |2 +-
> src/gallium/tests/trivial/tri.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/tests/trivial/quad-tex.c
> b/src/gallium/tests/trivial/quad-tex.c
> index c09e09a..0d38012 100644
> --- a/src/gallium/tests/trivial/quad-tex.c
> +++ b/src/gallium/tests/trivial/quad-tex.c
> @@ -266,7 +266,7 @@ static void init_prog(struct program *p)
> const uint semantic_names[] = { TGSI_SEMANTIC_POSITION,
> TGSI_SEMANTIC_GENERIC };
> const uint semantic_indexes[] = { 0, 0 };
> - p->vs = util_make_vertex_passthrough_shader(p->pipe, 2,
> semantic_names, semantic_indexes);
> + p->vs = util_make_vertex_passthrough_shader(p->pipe, 2,
> semantic_names, semantic_indexes, FALSE);
> }
>
> /* fragment shader */
> diff --git a/src/gallium/tests/trivial/tri.c
> b/src/gallium/tests/trivial/tri.c
> index dcc5a22..13cc801 100644
> --- a/src/gallium/tests/trivial/tri.c
> +++ b/src/gallium/tests/trivial/tri.c
> @@ -211,7 +211,7 @@ static void init_prog(struct program *p)
> const uint semantic_names[] = {
> TGSI_SEMANTIC_POSITION,
>
> TGSI_SEMANTIC_COLOR };
> const uint semantic_indexes[] = { 0, 0 };
> - p->vs =
> util_make_vertex_passthrough_shader(p->pipe, 2, semantic_names,
> semantic_indexes);
> + p->vs =
> util_make_vertex_passthrough_shader(p->pipe, 2, semantic_names,
> semantic_indexes, FALSE);
> }
>
> /* fragment shader */
> --
> 1.7.10.4
>
> ___
> 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 v4 0/8] Gallium Nine
I'm not, in principle, opposed to merging st/nine into the tree. I've reviewed all the patches that I'm qualified to review (which is the vast minority of them -- 3 total), and I have outstanding feedback on one of them (the atomic stuff). I've asked Axel to provide a sample program which could be used as the basis of a set of piglit tests that target d3d9 directly (a stand-alone linux program that draws a single triangle). This removes the dependency on wine (which, at present, has no intention on merging their patches). This will allow me (and other developers) to verify any changes we make to st/nine as API's change/etc without having to worry about futzing with wine to test things out. Cheers, -ilia On Mon, Nov 17, 2014 at 11:02 AM, Axel Davy wrote: > Sorry, patch 4 is too big the mailing list. > > The entire serie can be found here: > https://github.com/iXit/Mesa-3D/commits/for-upstream-5 > > On 17/11/2014 16:58, Axel Davy wrote : > >> Hi, >> >> Here is last (4th) iteration of Gallium Nine patches. >> >> We have integrated the new feedback we have got and hope >> the status of the serie is good enough now for merge. >> >> >> Thanks, >> >> Axel Davy >> >> Axel Davy (2): >>nine: Add drirc options (v2) >>nine: Implement threadpool >> >> Christoph Bumiller (5): >>tgsi/ureg: add ureg_UARL shortcut (v2) >>winsys/sw/wrapper: implement is_displaytarget_format_supported for >> swrast >>gallium/auxiliary: implement sw_probe_wrapped (v2) >>gallium/auxiliary: add inc and dec alternative with return (v2) >>gallium/auxiliary: add contained and rect checks (v6) >> >> Joakim Sindholt (1): >>nine: Add state tracker nine for Direct3D9 (v3) >> >> configure.ac | 37 + >> include/D3D9/d3d9.h| 1858 +++ >> include/D3D9/d3d9caps.h| 387 +++ >> include/D3D9/d3d9types.h | 1797 ++ >> include/d3dadapter/d3dadapter9.h | 101 + >> include/d3dadapter/drm.h | 44 + >> include/d3dadapter/present.h | 136 + >> src/gallium/Automake.inc |3 +- >> src/gallium/Makefile.am|4 + >> src/gallium/auxiliary/pipe-loader/pipe_loader.h| 11 + >> src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 23 + >> .../auxiliary/target-helpers/inline_sw_helper.h| 28 + >> src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h |1 + >> src/gallium/auxiliary/util/u_atomic.h | 78 + >> src/gallium/auxiliary/util/u_box.h | 118 + >> src/gallium/auxiliary/util/u_rect.h| 18 + >> src/gallium/state_trackers/nine/Makefile.am| 13 + >> src/gallium/state_trackers/nine/Makefile.sources | 73 + >> src/gallium/state_trackers/nine/README | 78 + >> src/gallium/state_trackers/nine/adapter9.c | 1091 ++ >> src/gallium/state_trackers/nine/adapter9.h | 139 + >> .../state_trackers/nine/authenticatedchannel9.c| 78 + >> .../state_trackers/nine/authenticatedchannel9.h| 65 + >> src/gallium/state_trackers/nine/basetexture9.c | 504 +++ >> src/gallium/state_trackers/nine/basetexture9.h | 138 + >> src/gallium/state_trackers/nine/cryptosession9.c | 115 + >> src/gallium/state_trackers/nine/cryptosession9.h | 86 + >> src/gallium/state_trackers/nine/cubetexture9.c | 274 ++ >> src/gallium/state_trackers/nine/cubetexture9.h | 79 + >> src/gallium/state_trackers/nine/device9.c | 3458 >> >> src/gallium/state_trackers/nine/device9.h | 801 + >> src/gallium/state_trackers/nine/device9ex.c| 400 +++ >> src/gallium/state_trackers/nine/device9ex.h| 149 + >> src/gallium/state_trackers/nine/device9video.c | 62 + >> src/gallium/state_trackers/nine/device9video.h | 57 + >> src/gallium/state_trackers/nine/guid.c | 66 + >> src/gallium/state_trackers/nine/guid.h | 36 + >> src/gallium/state_trackers/nine/indexbuffer9.c | 218 ++ >> src/gallium/state_trackers/nine/indexbuffer9.h | 88 + >> src/gallium/state_trackers/nine/iunknown.c | 126 + >> src/gallium/state_trackers/nine/iunknown.h | 153 + >> src/gallium/state_trackers/nine/nine_debug.c | 104 + >> src/gallium/state_trackers/nine/nine_debug.h | 135 + >> src/gallium/state_trackers/nine/nine_defines.h | 55 + >> src/gallium/state_trackers/nine/nine_dump.c| 813 + >> src/gallium/state_trackers/nine/nine_dump.h| 52 + >> src/gallium/state_trackers/nine/nine_ff.c | 2257 + >> src/gallium/state_trackers/nine/nine_ff.h | 32 + >> src/gallium/state_trackers/nine/nine_helpers.c | 100 + >> src/gallium/state_trackers/nine/
Re: [Mesa-dev] [PATCH 11/16] glsl: Add ir_binop_pow to get_range
2014-11-17 18:28 GMT+01:00 Thomas Helland :
> 2014-11-17 15:48 GMT+01:00 Bruno Jimenez :
>> On Mon, 2014-11-17 at 02:51 +0100, Thomas Helland wrote:
>>> The spec states that pow is undefined for x < 0.
>>> Just set the range to correspond to a constant 0
>>> if this is the case.
>>> ---
>>> src/glsl/opt_minmax.cpp | 11 +++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
>>> index 9852dd9..ad8c88a 100644
>>> --- a/src/glsl/opt_minmax.cpp
>>> +++ b/src/glsl/opt_minmax.cpp
>>> @@ -335,6 +335,17 @@ get_range(ir_rvalue *rval)
>>> high = add(r0.high, r1.high)->constant_expression_value();
>>> return minmax_range(low, high);
>>>
>>> + case ir_binop_pow:
>>> + r0 = get_range(expr->operands[0]);
>>> + if (is_greater_than_or_equal_zero(r0.low))
>> ^^
>>
>> Hi,
>>
>> I think that you meant 'less' here.
>>
>> If not, sorry for the noise.
>>
>> - Bruno
>
> Hi,
>
> I think you've just fast-read it, what I meant here was:
> For x^y, if x is positive then we know that the result will always be
> positive.
>
> I guess you where thinking of the undefined behavior?
> That's handled in the part below.
>
> When I think about it we could cut a line of code here
> by saying that the low bound is always 0.0,
> since x is demanded to be >= 0,0 and it's undefined otherwise.
>
> - Thomas
Forgot to reply to list, sorry for that.
Looking at the commit message I guess that was what threw you off.
It's a bit centered around the undefined behavior,
without mentioning that it also handles the "correct" case.
That should probably be fixed before committing.
- Thomas
>
>>
>>> +low = new(mem_ctx) ir_constant(0.0f);
>>> + // Result is undefined so we can set the range to bikeshed.
>>> + if (is_less_than_zero(r0.high)) {
>>> +low = new(mem_ctx) ir_constant(0.0f);
>>> +high = new(mem_ctx) ir_constant(0.0f);
>>> + }
>>> + return minmax_range(low, high);
>>> +
>>>default:
>>> break;
>>>}
>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] r600g/compute: Don't leak cbufs in compute state
Not sure if that's the right place, but this framebuffer state is set
by the driver and not a state tracker. Compute shader read-write
resources (buffers, images) are implemented by the CB block on r600
and are referred to as RAT (random access target) in the register
docs. The first 0-7 binding slots are shared with colorbuffers and the
8-11 slots are dedicated to compute resources only. For GL extensions
that add read-write buffers and images, the maximum number of
read-write resources is (12 - number_of_colorbuffers) and they are
only supported in the pixel shader.
This craziness doesn't exist on SI, instead, TC just can do stores there.
Marek
On Mon, Nov 17, 2014 at 8:45 AM, Michel Dänzer wrote:
> On 14.11.2014 19:37, Marek Olšák wrote:
>> surface_destroy should never be called directly, because surfaces have
>> a reference counter. For unreferencing resources, use
>> pipe_surface_reference(&pointer, NULL). It will call surface_destroy
>> if needed.
>
> Indeed, if this was the right place for this, it could be done both
> easier and more robustly:
>
>for (int i = 0; i < fb_state->nr_cbufs; i++)
>pipe_surface_reference(&fb_state->cbufs[i], NULL);
>
>
>> On Fri, Nov 14, 2014 at 12:43 AM, Aaron Watry wrote:
>>> Walk the array of cbufs backwards and free all of them.
>>>
>>> v3: Rebase on top of changes since Aug 2014
>>>
>>> Signed-off-by: Aaron Watry
>>> ---
>>> src/gallium/drivers/r600/evergreen_compute.c | 9 +
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/r600/evergreen_compute.c
>>> b/src/gallium/drivers/r600/evergreen_compute.c
>>> index 90fdd79..4334743 100644
>>> --- a/src/gallium/drivers/r600/evergreen_compute.c
>>> +++ b/src/gallium/drivers/r600/evergreen_compute.c
>>> @@ -252,6 +252,15 @@ void evergreen_delete_compute_state(struct
>>> pipe_context *ctx, void* state)
>>> if (!shader)
>>> return;
>>>
>>> + if (shader->ctx){
>>> + struct pipe_framebuffer_state *fb_state =
>>> &shader->ctx->framebuffer.state;
>>> + for (int i = fb_state->nr_cbufs - 1; fb_state->nr_cbufs > 0
>>> ; i--){
>>> + shader->ctx->b.b.surface_destroy(ctx,
>>> fb_state->cbufs[i]);
>>> + fb_state->cbufs[i] = NULL;
>>> + fb_state->nr_cbufs--;
>>> + }
>>> + }
>>> +
>>> FREE(shader);
>>> }
>>>
>>> --
>>> 2.1.0
>>>
>>> ___
>>> 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
>>
>
>
> --
> Earthling Michel Dänzer| http://www.amd.com
> Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5] gallium/auxiliary: add inc and dec alternative with return (v3)
From: Christoph Bumiller
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
v3: Replace MSVC assembly by assert + warning during compilation
Signed-off-by: David Heidelberg
---
src/gallium/auxiliary/util/u_atomic.h | 72 +++
1 file changed, 72 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_atomic.h
b/src/gallium/auxiliary/util/u_atomic.h
index 2f2b42b..9279073 100644
--- a/src/gallium/auxiliary/util/u_atomic.h
+++ b/src/gallium/auxiliary/util/u_atomic.h
@@ -69,6 +69,18 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return __sync_add_and_fetch(v, 1);
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return __sync_sub_and_fetch(v, 1);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return __sync_val_compare_and_swap(v, old, _new);
@@ -116,6 +128,18 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return __sync_add_and_fetch(v, 1);
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return __sync_sub_and_fetch(v, 1);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return __sync_val_compare_and_swap(v, old, _new);
@@ -161,6 +185,18 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return __sync_add_and_fetch(v, 1);
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return __sync_sub_and_fetch(v, 1);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return __sync_val_compare_and_swap(v, old, _new);
@@ -186,6 +222,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
#define p_atomic_dec_zero(_v) ((boolean) --(*(_v)))
#define p_atomic_inc(_v) ((void) (*(_v))++)
#define p_atomic_dec(_v) ((void) (*(_v))--)
+#define p_atomic_inc_return(_v) ((*(_v))++)
+#define p_atomic_dec_return(_v) ((*(_v))--)
#define p_atomic_cmpxchg(_v, old, _new) (*(_v) == old ? *(_v) = (_new) : *(_v))
#endif
@@ -197,6 +235,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
#define PIPE_ATOMIC "MSVC x86 assembly"
+#include
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -236,6 +276,24 @@ p_atomic_dec(int32_t *v)
}
}
+#pragma message ( "Warning: p_atomic_dec_return and p_atomic_inc_return
unimplemented for PIPE_ATOMIC_ASM_MSVC_X86" )
+
+static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ (void) v;
+ assert(0);
+ return 0;
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ (void) v;
+ assert(0);
+ return 0;
+}
+
static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
@@ -288,6 +346,12 @@ p_atomic_inc(int32_t *v)
_InterlockedIncrement((long *)v);
}
+static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return _InterlockedIncrement((long *)v);
+}
+
static INLINE void
p_atomic_dec(int32_t *v)
{
@@ -295,6 +359,12 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return _InterlockedDecrement((long *)v);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return _InterlockedCompareExchange((long *)v, _new, old);
@@ -329,6 +399,8 @@ p_atomic_dec_zero(int32_t *v)
#define p_atomic_inc(_v) atomic_inc_32((uint32_t *) _v)
#define p_atomic_dec(_v) atomic_dec_32((uint32_t *) _v)
+#define p_atomic_inc_return(_v) atomic_inc_32_nv((uint32_t *) _v)
+#define p_atomic_dec_return(_v) atomic_dec_32_nv((uint32_t *) _v)
#define p_atomic_cmpxchg(_v, _old, _new) \
atomic_cas_32( (uint32_t *) _v, (uint32_t) _old, (uint32_t) _new)
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5] gallium/auxiliary: add inc and dec alternative with return (v3)
On Mon, Nov 17, 2014 at 1:20 PM, Axel Davy wrote:
> From: Christoph Bumiller
>
> At this moment we use only zero or positive values.
>
> v2: Implement it for also for Solaris, MSVC assembly
> and enable for other combinations.
>
> v3: Replace MSVC assembly by assert + warning during compilation
>
> Signed-off-by: David Heidelberg
> ---
> src/gallium/auxiliary/util/u_atomic.h | 72
> +++
> 1 file changed, 72 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_atomic.h
> b/src/gallium/auxiliary/util/u_atomic.h
> index 2f2b42b..9279073 100644
> --- a/src/gallium/auxiliary/util/u_atomic.h
> +++ b/src/gallium/auxiliary/util/u_atomic.h
> @@ -69,6 +69,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -116,6 +128,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -161,6 +185,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -186,6 +222,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> #define p_atomic_dec_zero(_v) ((boolean) --(*(_v)))
> #define p_atomic_inc(_v) ((void) (*(_v))++)
> #define p_atomic_dec(_v) ((void) (*(_v))--)
> +#define p_atomic_inc_return(_v) ((*(_v))++)
> +#define p_atomic_dec_return(_v) ((*(_v))--)
> #define p_atomic_cmpxchg(_v, old, _new) (*(_v) == old ? *(_v) = (_new) :
> *(_v))
>
> #endif
> @@ -197,6 +235,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
>
> #define PIPE_ATOMIC "MSVC x86 assembly"
>
> +#include
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> @@ -236,6 +276,24 @@ p_atomic_dec(int32_t *v)
> }
> }
>
> +#pragma message ( "Warning: p_atomic_dec_return and p_atomic_inc_return
> unimplemented for PIPE_ATOMIC_ASM_MSVC_X86" )
... but nothing uses these functions that gets compiled by this
compiler. So you get a warning message on anything that includes
atomics (i.e. everything), but there's no actual issue. This seems
suboptimal.
What about just not having the functions there at all? Would that
cause any issues (unless someone tried to build st/nine)? I guess the
concern is that it would allow someone to foolishly start using these
primitives in MSVC-compiled code and then the vmware guys would be
left picking up the pieces.
OTOH, it seems fair to get them to provide the correct implementation
since they're the ones that care about the platform.
OTTH, I've spent more time typing this e-mail than it would take to
look up how to do this properly, so... why not just do that? :)
> +
> +static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + (void) v;
> + assert(0);
> + return 0;
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + (void) v;
> + assert(0);
> + return 0;
> +}
> +
> static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> @@ -288,6 +346,12 @@ p_atomic_inc(int32_t *v)
> _InterlockedIncrement((long *)v);
> }
>
> +static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return _InterlockedIncrement((long *)v);
> +}
> +
> static INLINE void
> p_atomic_dec(int32_t *v)
> {
> @@ -295,6 +359,12 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return _InterlockedDecrement((long *)v);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return _InterlockedCompareExchange((long *)v, _new, old);
> @@ -329,6 +399,8 @@ p_atomic_dec_zero(int32_t *v)
>
> #define p_atomic_inc(_v) atomic_inc_32((uint32_t *) _v)
> #define p_atomic_dec(_v) atomic_dec_32((uint32_t *) _v)
> +#define p_atomic_inc_return(_v) atomic_inc_32_nv((uint32_t *) _v)
> +#define p_atomic_dec_return(_v) atomic_dec_32_nv((uint32_t *) _v)
>
> #define p_atomic_cmpxchg(_v, _old, _new) \
> atomic_cas_32( (uint32_t *) _v, (uint32_t) _old, (uint32_t) _new)
> --
> 2.1.0
>
> ___
> mesa-dev mailing l
[Mesa-dev] [PATCH] gallium/auxiliary: add inc and dec alternative with return (v4)
From: Christoph Bumiller
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
v3: Replace MSVC assembly by assert + warning during compilation
v4: remove inc and dec with return for MSVC assembly
Signed-off-by: David Heidelberg
---
src/gallium/auxiliary/util/u_atomic.h | 52 +++
1 file changed, 52 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_atomic.h
b/src/gallium/auxiliary/util/u_atomic.h
index 2f2b42b..9731aa0 100644
--- a/src/gallium/auxiliary/util/u_atomic.h
+++ b/src/gallium/auxiliary/util/u_atomic.h
@@ -69,6 +69,18 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return __sync_add_and_fetch(v, 1);
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return __sync_sub_and_fetch(v, 1);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return __sync_val_compare_and_swap(v, old, _new);
@@ -116,6 +128,18 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return __sync_add_and_fetch(v, 1);
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return __sync_sub_and_fetch(v, 1);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return __sync_val_compare_and_swap(v, old, _new);
@@ -161,6 +185,18 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return __sync_add_and_fetch(v, 1);
+}
+
+static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return __sync_sub_and_fetch(v, 1);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return __sync_val_compare_and_swap(v, old, _new);
@@ -186,6 +222,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
#define p_atomic_dec_zero(_v) ((boolean) --(*(_v)))
#define p_atomic_inc(_v) ((void) (*(_v))++)
#define p_atomic_dec(_v) ((void) (*(_v))--)
+#define p_atomic_inc_return(_v) ((*(_v))++)
+#define p_atomic_dec_return(_v) ((*(_v))--)
#define p_atomic_cmpxchg(_v, old, _new) (*(_v) == old ? *(_v) = (_new) : *(_v))
#endif
@@ -288,6 +326,12 @@ p_atomic_inc(int32_t *v)
_InterlockedIncrement((long *)v);
}
+static INLINE int32_t
+p_atomic_inc_return(int32_t *v)
+{
+ return _InterlockedIncrement((long *)v);
+}
+
static INLINE void
p_atomic_dec(int32_t *v)
{
@@ -295,6 +339,12 @@ p_atomic_dec(int32_t *v)
}
static INLINE int32_t
+p_atomic_dec_return(int32_t *v)
+{
+ return _InterlockedDecrement((long *)v);
+}
+
+static INLINE int32_t
p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
{
return _InterlockedCompareExchange((long *)v, _new, old);
@@ -329,6 +379,8 @@ p_atomic_dec_zero(int32_t *v)
#define p_atomic_inc(_v) atomic_inc_32((uint32_t *) _v)
#define p_atomic_dec(_v) atomic_dec_32((uint32_t *) _v)
+#define p_atomic_inc_return(_v) atomic_inc_32_nv((uint32_t *) _v)
+#define p_atomic_dec_return(_v) atomic_dec_32_nv((uint32_t *) _v)
#define p_atomic_cmpxchg(_v, _old, _new) \
atomic_cas_32( (uint32_t *) _v, (uint32_t) _old, (uint32_t) _new)
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/auxiliary: add inc and dec alternative with return (v4)
On Mon, Nov 17, 2014 at 2:05 PM, Axel Davy wrote:
> From: Christoph Bumiller
>
> At this moment we use only zero or positive values.
>
> v2: Implement it for also for Solaris, MSVC assembly
> and enable for other combinations.
>
> v3: Replace MSVC assembly by assert + warning during compilation
>
> v4: remove inc and dec with return for MSVC assembly
Reviewed-by: Ilia Mirkin
I guess the people who care about MSVC will have to supply the
implementation when something other than st/nine starts using these
helpers. I think that's fair.
>
> Signed-off-by: David Heidelberg
> ---
> src/gallium/auxiliary/util/u_atomic.h | 52
> +++
> 1 file changed, 52 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_atomic.h
> b/src/gallium/auxiliary/util/u_atomic.h
> index 2f2b42b..9731aa0 100644
> --- a/src/gallium/auxiliary/util/u_atomic.h
> +++ b/src/gallium/auxiliary/util/u_atomic.h
> @@ -69,6 +69,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -116,6 +128,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -161,6 +185,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -186,6 +222,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> #define p_atomic_dec_zero(_v) ((boolean) --(*(_v)))
> #define p_atomic_inc(_v) ((void) (*(_v))++)
> #define p_atomic_dec(_v) ((void) (*(_v))--)
> +#define p_atomic_inc_return(_v) ((*(_v))++)
> +#define p_atomic_dec_return(_v) ((*(_v))--)
> #define p_atomic_cmpxchg(_v, old, _new) (*(_v) == old ? *(_v) = (_new) :
> *(_v))
>
> #endif
> @@ -288,6 +326,12 @@ p_atomic_inc(int32_t *v)
> _InterlockedIncrement((long *)v);
> }
>
> +static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return _InterlockedIncrement((long *)v);
> +}
> +
> static INLINE void
> p_atomic_dec(int32_t *v)
> {
> @@ -295,6 +339,12 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return _InterlockedDecrement((long *)v);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return _InterlockedCompareExchange((long *)v, _new, old);
> @@ -329,6 +379,8 @@ p_atomic_dec_zero(int32_t *v)
>
> #define p_atomic_inc(_v) atomic_inc_32((uint32_t *) _v)
> #define p_atomic_dec(_v) atomic_dec_32((uint32_t *) _v)
> +#define p_atomic_inc_return(_v) atomic_inc_32_nv((uint32_t *) _v)
> +#define p_atomic_dec_return(_v) atomic_dec_32_nv((uint32_t *) _v)
>
> #define p_atomic_cmpxchg(_v, _old, _new) \
> atomic_cas_32( (uint32_t *) _v, (uint32_t) _old, (uint32_t) _new)
> --
> 2.1.0
>
> ___
> 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 v5] gallium/auxiliary: add inc and dec alternative with return (v3)
On Mon, Nov 17, 2014 at 12:20 PM, Axel Davy wrote:
> From: Christoph Bumiller
>
> At this moment we use only zero or positive values.
>
> v2: Implement it for also for Solaris, MSVC assembly
> and enable for other combinations.
>
> v3: Replace MSVC assembly by assert + warning during compilation
>
> Signed-off-by: David Heidelberg
> ---
> src/gallium/auxiliary/util/u_atomic.h | 72
> +++
> 1 file changed, 72 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_atomic.h
> b/src/gallium/auxiliary/util/u_atomic.h
> index 2f2b42b..9279073 100644
> --- a/src/gallium/auxiliary/util/u_atomic.h
> +++ b/src/gallium/auxiliary/util/u_atomic.h
> @@ -69,6 +69,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -116,6 +128,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -161,6 +185,18 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return __sync_add_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return __sync_sub_and_fetch(v, 1);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return __sync_val_compare_and_swap(v, old, _new);
> @@ -186,6 +222,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> #define p_atomic_dec_zero(_v) ((boolean) --(*(_v)))
> #define p_atomic_inc(_v) ((void) (*(_v))++)
> #define p_atomic_dec(_v) ((void) (*(_v))--)
> +#define p_atomic_inc_return(_v) ((*(_v))++)
> +#define p_atomic_dec_return(_v) ((*(_v))--)
> #define p_atomic_cmpxchg(_v, old, _new) (*(_v) == old ? *(_v) = (_new) :
> *(_v))
>
> #endif
> @@ -197,6 +235,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
>
> #define PIPE_ATOMIC "MSVC x86 assembly"
>
> +#include
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> @@ -236,6 +276,24 @@ p_atomic_dec(int32_t *v)
> }
> }
>
> +#pragma message ( "Warning: p_atomic_dec_return and p_atomic_inc_return
> unimplemented for PIPE_ATOMIC_ASM_MSVC_X86" )
> +
> +static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + (void) v;
> + assert(0);
> + return 0;
> +}
>
Why isn't _InterlockedIncrement() used here? It is used for the void
functions. If you read the definition of _InterlockedIncrement() it returns
the new value -- isn't that what is needed?
> +
> +static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + (void) v;
> + assert(0);
> + return 0;
> +}
>
Similarly here.
> +
> static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> @@ -288,6 +346,12 @@ p_atomic_inc(int32_t *v)
> _InterlockedIncrement((long *)v);
> }
>
> +static INLINE int32_t
> +p_atomic_inc_return(int32_t *v)
> +{
> + return _InterlockedIncrement((long *)v);
> +}
> +
> static INLINE void
> p_atomic_dec(int32_t *v)
> {
> @@ -295,6 +359,12 @@ p_atomic_dec(int32_t *v)
> }
>
> static INLINE int32_t
> +p_atomic_dec_return(int32_t *v)
> +{
> + return _InterlockedDecrement((long *)v);
> +}
> +
> +static INLINE int32_t
> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> {
> return _InterlockedCompareExchange((long *)v, _new, old);
> @@ -329,6 +399,8 @@ p_atomic_dec_zero(int32_t *v)
>
> #define p_atomic_inc(_v) atomic_inc_32((uint32_t *) _v)
> #define p_atomic_dec(_v) atomic_dec_32((uint32_t *) _v)
> +#define p_atomic_inc_return(_v) atomic_inc_32_nv((uint32_t *) _v)
> +#define p_atomic_dec_return(_v) atomic_dec_32_nv((uint32_t *) _v)
>
> #define p_atomic_cmpxchg(_v, _old, _new) \
> atomic_cas_32( (uint32_t *) _v, (uint32_t) _old, (uint32_t) _new)
> --
> 2.1.0
>
> ___
> 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 v5] gallium/auxiliary: add inc and dec alternative with return (v3)
On Mon, Nov 17, 2014 at 2:15 PM, Patrick Baggett
wrote:
>
>
> On Mon, Nov 17, 2014 at 12:20 PM, Axel Davy wrote:
>>
>> From: Christoph Bumiller
>>
>> At this moment we use only zero or positive values.
>>
>> v2: Implement it for also for Solaris, MSVC assembly
>> and enable for other combinations.
>>
>> v3: Replace MSVC assembly by assert + warning during compilation
>>
>> Signed-off-by: David Heidelberg
>> ---
>> src/gallium/auxiliary/util/u_atomic.h | 72
>> +++
>> 1 file changed, 72 insertions(+)
>>
>> diff --git a/src/gallium/auxiliary/util/u_atomic.h
>> b/src/gallium/auxiliary/util/u_atomic.h
>> index 2f2b42b..9279073 100644
>> --- a/src/gallium/auxiliary/util/u_atomic.h
>> +++ b/src/gallium/auxiliary/util/u_atomic.h
>> @@ -69,6 +69,18 @@ p_atomic_dec(int32_t *v)
>> }
>>
>> static INLINE int32_t
>> +p_atomic_inc_return(int32_t *v)
>> +{
>> + return __sync_add_and_fetch(v, 1);
>> +}
>> +
>> +static INLINE int32_t
>> +p_atomic_dec_return(int32_t *v)
>> +{
>> + return __sync_sub_and_fetch(v, 1);
>> +}
>> +
>> +static INLINE int32_t
>> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
>> {
>> return __sync_val_compare_and_swap(v, old, _new);
>> @@ -116,6 +128,18 @@ p_atomic_dec(int32_t *v)
>> }
>>
>> static INLINE int32_t
>> +p_atomic_inc_return(int32_t *v)
>> +{
>> + return __sync_add_and_fetch(v, 1);
>> +}
>> +
>> +static INLINE int32_t
>> +p_atomic_dec_return(int32_t *v)
>> +{
>> + return __sync_sub_and_fetch(v, 1);
>> +}
>> +
>> +static INLINE int32_t
>> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
>> {
>> return __sync_val_compare_and_swap(v, old, _new);
>> @@ -161,6 +185,18 @@ p_atomic_dec(int32_t *v)
>> }
>>
>> static INLINE int32_t
>> +p_atomic_inc_return(int32_t *v)
>> +{
>> + return __sync_add_and_fetch(v, 1);
>> +}
>> +
>> +static INLINE int32_t
>> +p_atomic_dec_return(int32_t *v)
>> +{
>> + return __sync_sub_and_fetch(v, 1);
>> +}
>> +
>> +static INLINE int32_t
>> p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
>> {
>> return __sync_val_compare_and_swap(v, old, _new);
>> @@ -186,6 +222,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t
>> _new)
>> #define p_atomic_dec_zero(_v) ((boolean) --(*(_v)))
>> #define p_atomic_inc(_v) ((void) (*(_v))++)
>> #define p_atomic_dec(_v) ((void) (*(_v))--)
>> +#define p_atomic_inc_return(_v) ((*(_v))++)
>> +#define p_atomic_dec_return(_v) ((*(_v))--)
>> #define p_atomic_cmpxchg(_v, old, _new) (*(_v) == old ? *(_v) = (_new) :
>> *(_v))
>>
>> #endif
>> @@ -197,6 +235,8 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t
>> _new)
>>
>> #define PIPE_ATOMIC "MSVC x86 assembly"
>>
>> +#include
>> +
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>> @@ -236,6 +276,24 @@ p_atomic_dec(int32_t *v)
>> }
>> }
>>
>> +#pragma message ( "Warning: p_atomic_dec_return and p_atomic_inc_return
>> unimplemented for PIPE_ATOMIC_ASM_MSVC_X86" )
>> +
>> +static INLINE int32_t
>> +p_atomic_inc_return(int32_t *v)
>> +{
>> + (void) v;
>> + assert(0);
>> + return 0;
>> +}
>
>
> Why isn't _InterlockedIncrement() used here? It is used for the void
> functions. If you read the definition of _InterlockedIncrement() it returns
> the new value -- isn't that what is needed?
Looking at u_atomic.h there is a section that uses
PIPE_ATOMIC_ASM_MSVC_X86 and has explicit assembly, and there's a
section that uses PIPE_ATOMIC_MSVC_INTRINSIC and has intrinsics. No
clue whatsoever what the difference between them is, but presumably it
doesn't exist solely for the purpose of annoying developers...
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5] gallium/auxiliary: add inc and dec alternative with return (v3)
>
>
> Looking at u_atomic.h there is a section that uses
> PIPE_ATOMIC_ASM_MSVC_X86 and has explicit assembly, and there's a
> section that uses PIPE_ATOMIC_MSVC_INTRINSIC and has intrinsics. No
> clue whatsoever what the difference between them is, but presumably it
> doesn't exist solely for the purpose of annoying developers...
>
I can't think of a good reason; I would be interested in knowing why. Last
time I checked, MSVC is terrible at optimizing around __asm{} blocks and if
I recall, only x86 (i.e. 32-bit) supports inline assembly. This is a bit
off-topic though...
>
> -ilia
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/include/pipe: Added interface for atomic counter buffers in pipe
Hi,
I agree with the solution. Considering "images" as "buffers" or "buffers"
as "images" (as they are operated inside shaders but not texture units)
makes sense. I think we can make atomic buffers as a part of
ARB_shader_image_load_store. Because, images are 2D array of buffers with
atomic operations run on them.
You have mentioned in our previous conversation about the un-necessity of
store. The spec for ARB_shader_image_load_store says imageStore(). If we
are implementing the same for atomics, then we have to use store for it too.
Thank you!!
On Mon, Nov 17, 2014 at 11:28 AM, Ilia Mirkin wrote:
> Because shader resources were already specified as pipe_surfaces (in
> the existing, albeit presently unused API). A pipe_surface is a
> wrapper around a resource that specifies what "view" of the resource
> should be writable, and attaches an optional format to that resource.
> Normally pipe_surfaces are used for render targets, but it applies
> just as well here. It applies especially well with a view towards
> ARB_shader_image_load_store.
>
> It's conceivable to make a totally separate thing for atomic buffers,
> but there's no good reason to -- they will have to be handled in
> essentially the same way as regular "image" surfaces will for
> ARB_shader_image_load_store.
>
> Cheers,
>
> -ilia
>
> On Mon, Nov 17, 2014 at 11:19 AM, Aditya Avinash
> wrote:
> > Hi,
> > I am having difficulty in understanding why you implemented pipe_surface
> in
> > st_atom_atomicbuf.c.
> >
> > On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash <
> adityaavina...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> On Sunday, November 16, 2014, Ilia Mirkin wrote:
> >>>
> >>> The direction I went in was by adapting the shader resources interface
> >>> for this. I believe it will be possible to use for
> >>> shader_image_load_store as well.
> >>
> >>
> >> I asked some questions on mailing list about the implementation. I took
> >> the same path as uniform buffers. But, I realized that it's not
> efficient to
> >> do that.
> >>
> >>>
> >>> See https://github.com/imirkin/mesa/commits/atomic
> >>>
> >>
> >> The commits are similar to my previous patch. I was doing atomics
> similar
> >> to uniform buffers, Now I was changing cso_context.
> >>
> >>>
> >>> I believe that makes a lot more sense than creating a special counter
> >>> buffer type only to be used for this. pipe_surface has the requisite
> >>> offset/etc options.
> >>
> >>
> >> I thought of using uniform buffer data structure with certain flags
> which
> >> differentiate between atomics, uniforms, index. Like a generic buffer.
> >>
> >>>
> >>> I feel like I've mentioned this before when you asked questions, but
> >>> I'd highly recommend taking my work and improving on it (or at least
> >>> understanding it). It's at the point where a driver can implement the
> >>> backend logic, although some of the mesa/st bits are going to be
> >>> subject to discussion (and need fixing, it messes up the DCE tgsi
> >>> pass, so I just disabled it).
> >>>
> >>> On Thu, Nov 13, 2014 at 12:18 AM, adityaatluri <
> adityaavina...@gmail.com>
> >>> wrote:
> >>> > ---
> >>> > src/gallium/include/pipe/p_context.h | 5 +
> >>> > src/gallium/include/pipe/p_defines.h | 7 ++-
> >>> > src/gallium/include/pipe/p_state.h | 10 ++
> >>> > 3 files changed, 21 insertions(+), 1 deletion(-)
> >>> >
> >>> > diff --git a/src/gallium/include/pipe/p_context.h
> >>> > b/src/gallium/include/pipe/p_context.h
> >>> > index af5674f..bf3be31 100644
> >>> > --- a/src/gallium/include/pipe/p_context.h
> >>> > +++ b/src/gallium/include/pipe/p_context.h
> >>> > @@ -44,6 +44,7 @@ struct pipe_blit_info;
> >>> > struct pipe_box;
> >>> > struct pipe_clip_state;
> >>> > struct pipe_constant_buffer;
> >>> > +struct pipe_counter_buffer;
> >>> > struct pipe_depth_stencil_alpha_state;
> >>> > struct pipe_draw_info;
> >>> > struct pipe_fence_handle;
> >>> > @@ -201,6 +202,10 @@ struct pipe_context {
> >>> > uint shader, uint index,
> >>> > struct pipe_constant_buffer *buf );
> >>> >
> >>> > + void (*set_counter_buffer)( struct pipe_context *,
> >>> > + uint shader, uint index,
> >>> > + struct pipe_counter_buffer *buf );
> >>> > +
> >>> > void (*set_framebuffer_state)( struct pipe_context *,
> >>> >const struct
> pipe_framebuffer_state
> >>> > * );
> >>> >
> >>> > diff --git a/src/gallium/include/pipe/p_defines.h
> >>> > b/src/gallium/include/pipe/p_defines.h
> >>> > index 8c4e415..717ab6a 100644
> >>> > --- a/src/gallium/include/pipe/p_defines.h
> >>> > +++ b/src/gallium/include/pipe/p_defines.h
> >>> > @@ -341,6 +341,7 @@ enum pipe_flush_flags {
> >>> > #define PIPE_BIND_VERTEX_BUFFER(1 << 4) /*
> set_vertex_buffers
> >>> > */
> >>> > #define PIPE_BIND_INDEX_BUFFER (1 << 5) /* draw_elements */
> >>> > #define PIPE_BIND_CON
Re: [Mesa-dev] [PATCH] gallium/include/pipe: Added interface for atomic counter buffers in pipe
The issue with STORE isn't whether it's necessary (it is!), but the
exact semantics of the TGSI opcode. The way I have it in my patch
right now is that it doesn't have a destination, which upsets the dead
code removal logic in st_glsl_to_tgsi greatly. For now I've just
commented it out, but that's not a long-term solution. See current
docs at http://gallium.readthedocs.org/en/latest/tgsi.html#opcode-STORE
-- I've changed it by moving the RES[] to the end, which is consistent
with how e.g. TEX works.
On Mon, Nov 17, 2014 at 2:39 PM, Aditya Avinash
wrote:
> Hi,
> I agree with the solution. Considering "images" as "buffers" or "buffers" as
> "images" (as they are operated inside shaders but not texture units) makes
> sense. I think we can make atomic buffers as a part of
> ARB_shader_image_load_store. Because, images are 2D array of buffers with
> atomic operations run on them.
>
> You have mentioned in our previous conversation about the un-necessity of
> store. The spec for ARB_shader_image_load_store says imageStore(). If we are
> implementing the same for atomics, then we have to use store for it too.
>
> Thank you!!
>
> On Mon, Nov 17, 2014 at 11:28 AM, Ilia Mirkin wrote:
>>
>> Because shader resources were already specified as pipe_surfaces (in
>> the existing, albeit presently unused API). A pipe_surface is a
>> wrapper around a resource that specifies what "view" of the resource
>> should be writable, and attaches an optional format to that resource.
>> Normally pipe_surfaces are used for render targets, but it applies
>> just as well here. It applies especially well with a view towards
>> ARB_shader_image_load_store.
>>
>> It's conceivable to make a totally separate thing for atomic buffers,
>> but there's no good reason to -- they will have to be handled in
>> essentially the same way as regular "image" surfaces will for
>> ARB_shader_image_load_store.
>>
>> Cheers,
>>
>> -ilia
>>
>> On Mon, Nov 17, 2014 at 11:19 AM, Aditya Avinash
>> wrote:
>> > Hi,
>> > I am having difficulty in understanding why you implemented pipe_surface
>> > in
>> > st_atom_atomicbuf.c.
>> >
>> > On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash
>> >
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Sunday, November 16, 2014, Ilia Mirkin wrote:
>> >>>
>> >>> The direction I went in was by adapting the shader resources interface
>> >>> for this. I believe it will be possible to use for
>> >>> shader_image_load_store as well.
>> >>
>> >>
>> >> I asked some questions on mailing list about the implementation. I took
>> >> the same path as uniform buffers. But, I realized that it's not
>> >> efficient to
>> >> do that.
>> >>
>> >>>
>> >>> See https://github.com/imirkin/mesa/commits/atomic
>> >>>
>> >>
>> >> The commits are similar to my previous patch. I was doing atomics
>> >> similar
>> >> to uniform buffers, Now I was changing cso_context.
>> >>
>> >>>
>> >>> I believe that makes a lot more sense than creating a special counter
>> >>> buffer type only to be used for this. pipe_surface has the requisite
>> >>> offset/etc options.
>> >>
>> >>
>> >> I thought of using uniform buffer data structure with certain flags
>> >> which
>> >> differentiate between atomics, uniforms, index. Like a generic buffer.
>> >>
>> >>>
>> >>> I feel like I've mentioned this before when you asked questions, but
>> >>> I'd highly recommend taking my work and improving on it (or at least
>> >>> understanding it). It's at the point where a driver can implement the
>> >>> backend logic, although some of the mesa/st bits are going to be
>> >>> subject to discussion (and need fixing, it messes up the DCE tgsi
>> >>> pass, so I just disabled it).
>> >>>
>> >>> On Thu, Nov 13, 2014 at 12:18 AM, adityaatluri
>> >>>
>> >>> wrote:
>> >>> > ---
>> >>> > src/gallium/include/pipe/p_context.h | 5 +
>> >>> > src/gallium/include/pipe/p_defines.h | 7 ++-
>> >>> > src/gallium/include/pipe/p_state.h | 10 ++
>> >>> > 3 files changed, 21 insertions(+), 1 deletion(-)
>> >>> >
>> >>> > diff --git a/src/gallium/include/pipe/p_context.h
>> >>> > b/src/gallium/include/pipe/p_context.h
>> >>> > index af5674f..bf3be31 100644
>> >>> > --- a/src/gallium/include/pipe/p_context.h
>> >>> > +++ b/src/gallium/include/pipe/p_context.h
>> >>> > @@ -44,6 +44,7 @@ struct pipe_blit_info;
>> >>> > struct pipe_box;
>> >>> > struct pipe_clip_state;
>> >>> > struct pipe_constant_buffer;
>> >>> > +struct pipe_counter_buffer;
>> >>> > struct pipe_depth_stencil_alpha_state;
>> >>> > struct pipe_draw_info;
>> >>> > struct pipe_fence_handle;
>> >>> > @@ -201,6 +202,10 @@ struct pipe_context {
>> >>> > uint shader, uint index,
>> >>> > struct pipe_constant_buffer *buf );
>> >>> >
>> >>> > + void (*set_counter_buffer)( struct pipe_context *,
>> >>> > + uint shader, uint index,
>> >>> > + struct pipe_counter_buffer *buf );
>> >>> > +
>> >>> > v
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14/11/14 14:14, Emil Velikov wrote: > On 02/11/14 18:27, David Heidelberg wrote: >> Hello everyone! >> >> First I'd like thank you for great feedback. >> Sending third Gallium Nine merge request. We reduced number of commits >> to necessary minimum. I hope all proposed changes are incorporated in v3. >> >> Thank you >> To summarise: - Interface Afaict reusing gallium or wined3d internal interface is not an option for either project. - Two implementations On 14/11/14 16:15, Henri Verbeet wrote: > The main issue is probably that we'd really like to avoid having two > parallel implementations of the high-level d3d9 stuff. > Indeed yet I don't think that anyone will be too happy to remove the existing one, and with nine using a completely different approach it only makes sense to have it alongside the more mature wine d3d. - Performance While I'm not an OpenGL/Direct3D expert, the idea of jumping over one hurdle (d3d > hardware) as opposed to two (D3D > OpenGL > hardware) is always a win. I believe Marek nicely pointed the technical reasons. - GL extensions I feel that it's a bit too much to shoot the project down, because it does not introduce GL extensions that will be useful. After all the it aims to tackle the whole topic from a completely different angle. If you would like to propose new extensions, I don't think mesa devs will object. - Nine vs wine's d3d While not explicitly stated, there is a concern about using nine over wine's d3d library. Note that one has to _explicitly_ opt-in to use nine, with a fall-back to wine and also it does not hinder wine's d3d9,10,11... in any way. Henri, Considering the interface note able, would you say that any new implementation towards handling D3D9 in wine is acceptable ? Please note that I'm not talking about improving the existing one be that via GL extensions or otherwise. How about if such an implementation is disabled by default in the build, and people have to explicitly opt to (via regedit) use it ? A one that falls back to wine, when it does not work (missing driver or otherwise) and does not hinder your d3d10/d3d11 efforts ? If you're concerned about it's maintenance, I'm pretty sure that one of the guys can step in. If it's about wine <> mesa(nine) interface I would assume that the guys would love to hear your feedback (within reason of course). Lastly let's point out that there is a reason why we keep on talking about this - significant performance improvement [1] [2]. One that surpasses wine+CSMT and in some cases even the official/binary drivers on top of it. Can we work together so that both project benefit from this effort ? Thanks Emil [1] http://www.linuxsystems.it/2014/09/wine-vanilla-vs-csmt-d3dstream-vs-gallium-nine-vs-catalyst/ [2] https://www.youtube.com/playlist?list=PLfaZPGij0wwI69Bce1sbjLlcwRMWINYNy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 10.3.4 candidate
Hello all, As you may have noticed there are only three commits since 10.3.3, which imho are quite serious of people hitting those issues. Thus I do plan on releasing 10.3.4 this Friday. The usual summary with testing & stats will be out on Wednesday, as I would like to see if we'll have any additional patches for 10.3.4. As always if you have any comments, suggestions and/or objections, don't be shy to speak up. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: copy sampler_array_size field when copying instructions
The sampler_array_size field was added by "mesa/st: add support for
dynamic sampler offsets". But the field wasn't getting copied in
the get_pixel_transfer_visitor() or get_bitmap_visitor() functions.
The count_resources() function then didn't properly compute the
glsl_to_tgsi_visitor::samplers_used bitmask. Then, we didn't declare
all the sampler registers in st_translate_program(). Finally, we
asserted when we tried to emit a tgsi ureg src register with File =
TGSI_FILE_UNDEFINED.
Add the missing assignments and some new assertions to catch the
invalid register sooner.
Cc: "10.3, 10.4"
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index c10ad75..8e91c4b 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4022,6 +4022,7 @@ get_pixel_transfer_visitor(struct st_fragment_program *fp,
newinst = v->emit(NULL, inst->op, inst->dst, src_regs[0], src_regs[1],
src_regs[2]);
newinst->tex_target = inst->tex_target;
+ newinst->sampler_array_size = inst->sampler_array_size;
}
/* Make modifications to fragment program info. */
@@ -4101,6 +4102,7 @@ get_bitmap_visitor(struct st_fragment_program *fp,
newinst = v->emit(NULL, inst->op, inst->dst, src_regs[0], src_regs[1],
src_regs[2]);
newinst->tex_target = inst->tex_target;
+ newinst->sampler_array_size = inst->sampler_array_size;
}
/* Make modifications to fragment program info. */
@@ -4524,8 +4526,10 @@ compile_tgsi_instruction(struct st_translate *t,
inst->saturate,
clamp_dst_color_output);
- for (i = 0; i < num_src; i++)
+ for (i = 0; i < num_src; i++) {
+ assert(inst->src[i].file != PROGRAM_UNDEFINED);
src[i] = translate_src(t, &inst->src[i]);
+ }
switch(inst->op) {
case TGSI_OPCODE_BGNLOOP:
@@ -4555,6 +4559,7 @@ compile_tgsi_instruction(struct st_translate *t,
case TGSI_OPCODE_TG4:
case TGSI_OPCODE_LODQ:
src[num_src] = t->samplers[inst->sampler.index];
+ assert(src[num_src].File != TGSI_FILE_NULL);
if (inst->sampler.reladdr)
src[num_src] =
ureg_src_indirect(src[num_src], ureg_src(t->address[2]));
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radeonsi: support gl_FragCoord at integer pixel center
From: Marek Olšák No known benefit for OpenGL, but it doesn't hurt. --- src/gallium/drivers/radeonsi/si_pipe.c | 2 +- src/gallium/drivers/radeonsi/si_state_draw.c | 4 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeonsi/si_pipe.c b/src/gallium/drivers/radeonsi/si_pipe.c index 61a3885..19ad75a 100644 --- a/src/gallium/drivers/radeonsi/si_pipe.c +++ b/src/gallium/drivers/radeonsi/si_pipe.c @@ -183,6 +183,7 @@ static int si_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_MIXED_COLORBUFFER_FORMATS: case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT: case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER: + case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER: case PIPE_CAP_SM3: case PIPE_CAP_SEAMLESS_CUBE_MAP: case PIPE_CAP_PRIMITIVE_RESTART: @@ -240,7 +241,6 @@ static int si_get_param(struct pipe_screen* pscreen, enum pipe_cap param) /* Unsupported features. */ case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT: - case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER: case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS: case PIPE_CAP_FRAGMENT_COLOR_CLAMPED: case PIPE_CAP_VERTEX_COLOR_CLAMPED: diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c b/src/gallium/drivers/radeonsi/si_state_draw.c index f108282..674b4a0 100644 --- a/src/gallium/drivers/radeonsi/si_state_draw.c +++ b/src/gallium/drivers/radeonsi/si_state_draw.c @@ -262,6 +262,10 @@ static void si_shader_ps(struct si_shader *shader) spi_baryc_cntl |= S_0286E0_POS_FLOAT_LOCATION(2); break; } + + if (info->properties[TGSI_PROPERTY_FS_COORD_PIXEL_CENTER] == + TGSI_FS_COORD_PIXEL_CENTER_INTEGER) + spi_baryc_cntl |= S_0286E0_POS_FLOAT_ULC(1); break; } } -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radeonsi: support per-sample gl_FragCoord
From: Marek Olšák
Cc: 10.4
---
src/gallium/drivers/radeonsi/si_state_draw.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index d5b27e7..f108282 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -248,20 +248,21 @@ static void si_shader_ps(struct si_shader *shader)
for (i = 0; i < info->num_inputs; i++) {
switch (info->input_semantic_name[i]) {
case TGSI_SEMANTIC_POSITION:
- if (info->input_interpolate_loc[i] ==
- TGSI_INTERPOLATE_LOC_CENTROID) {
- /* SPI_BARYC_CNTL.POS_FLOAT_LOCATION
-* Possible vaules:
-* 0 -> Position = pixel center (default)
-* 1 -> Position = pixel centroid
-* 2 -> Position = iterated sample number XXX:
-*What does this mean?
-*/
+ /* SPI_BARYC_CNTL.POS_FLOAT_LOCATION
+* Possible vaules:
+* 0 -> Position = pixel center (default)
+* 1 -> Position = pixel centroid
+* 2 -> Position = at sample position
+*/
+ switch (info->input_interpolate_loc[i]) {
+ case TGSI_INTERPOLATE_LOC_CENTROID:
spi_baryc_cntl |=
S_0286E0_POS_FLOAT_LOCATION(1);
+ break;
+ case TGSI_INTERPOLATE_LOC_SAMPLE:
+ spi_baryc_cntl |=
S_0286E0_POS_FLOAT_LOCATION(2);
+ break;
}
- /* Fall through */
- case TGSI_SEMANTIC_FACE:
- continue;
+ break;
}
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] draw: implement TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION
From: Marek Olšák
Required by Nine. Tested with util_run_tests.
It's added to softpipe, llvmpipe, and r300g/swtcl.
---
src/gallium/auxiliary/draw/draw_context.c | 40 ++
src/gallium/auxiliary/draw/draw_llvm.c | 2 +-
src/gallium/auxiliary/draw/draw_private.h | 4 +++
.../auxiliary/draw/draw_pt_fetch_shade_emit.c | 2 +-
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c | 2 +-
.../draw/draw_pt_fetch_shade_pipeline_llvm.c | 2 +-
src/gallium/auxiliary/draw/draw_vs.c | 2 ++
src/gallium/drivers/llvmpipe/lp_screen.c | 2 ++
src/gallium/drivers/r300/r300_screen.c | 2 +-
src/gallium/drivers/softpipe/sp_screen.c | 2 ++
10 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_context.c
b/src/gallium/auxiliary/draw/draw_context.c
index 2b640b6..d473cfc 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -267,21 +267,48 @@ void draw_set_zs_format(struct draw_context *draw, enum
pipe_format format)
}
-static void update_clip_flags( struct draw_context *draw )
+static bool
+draw_is_vs_window_space(struct draw_context *draw)
{
- draw->clip_xy = !draw->driver.bypass_clip_xy;
+ if (draw->vs.vertex_shader) {
+ struct tgsi_shader_info *info = &draw->vs.vertex_shader->info;
+
+ return info->properties[TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION] != 0;
+ }
+ return false;
+}
+
+
+void
+draw_update_clip_flags(struct draw_context *draw)
+{
+ bool window_space = draw_is_vs_window_space(draw);
+
+ draw->clip_xy = !draw->driver.bypass_clip_xy && !window_space;
draw->guard_band_xy = (!draw->driver.bypass_clip_xy &&
draw->driver.guard_band_xy);
draw->clip_z = (!draw->driver.bypass_clip_z &&
- draw->rasterizer && draw->rasterizer->depth_clip);
+ draw->rasterizer && draw->rasterizer->depth_clip) &&
+ !window_space;
draw->clip_user = draw->rasterizer &&
- draw->rasterizer->clip_plane_enable != 0;
+ draw->rasterizer->clip_plane_enable != 0 &&
+ !window_space;
draw->guard_band_points_xy = draw->guard_band_xy ||
(draw->driver.bypass_clip_points &&
(draw->rasterizer &&
draw->rasterizer->point_tri_clip));
}
+
+void
+draw_update_viewport_flags(struct draw_context *draw)
+{
+ bool window_space = draw_is_vs_window_space(draw);
+
+ draw->bypass_viewport = window_space || draw->identity_viewport;
+}
+
+
/**
* Register new primitive rasterization/rendering state.
* This causes the drawing pipeline to be rebuilt.
@@ -295,7 +322,7 @@ void draw_set_rasterizer_state( struct draw_context *draw,
draw->rasterizer = raster;
draw->rast_handle = rast_handle;
- update_clip_flags(draw);
+ draw_update_clip_flags(draw);
}
}
@@ -322,7 +349,7 @@ void draw_set_driver_clipping( struct draw_context *draw,
draw->driver.bypass_clip_z = bypass_clip_z;
draw->driver.guard_band_xy = guard_band_xy;
draw->driver.bypass_clip_points = bypass_clip_points;
- update_clip_flags(draw);
+ draw_update_clip_flags(draw);
}
@@ -376,6 +403,7 @@ void draw_set_viewport_states( struct draw_context *draw,
viewport->translate[0] == 0.0f &&
viewport->translate[1] == 0.0f &&
viewport->translate[2] == 0.0f);
+ draw_update_viewport_flags(draw);
}
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 3a1b057..fbbe08b 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -1831,7 +1831,7 @@ draw_llvm_make_variant_key(struct draw_llvm *llvm, char
*store)
key->clip_xy = llvm->draw->clip_xy;
key->clip_z = llvm->draw->clip_z;
key->clip_user = llvm->draw->clip_user;
- key->bypass_viewport = llvm->draw->identity_viewport;
+ key->bypass_viewport = llvm->draw->bypass_viewport;
key->clip_halfz = llvm->draw->rasterizer->clip_halfz;
key->need_edgeflags = (llvm->draw->vs.edgeflag_output ? TRUE : FALSE);
key->ucp_enable = llvm->draw->rasterizer->clip_plane_enable;
diff --git a/src/gallium/auxiliary/draw/draw_private.h
b/src/gallium/auxiliary/draw/draw_private.h
index d8dc2ab..8d4e1cd 100644
--- a/src/gallium/auxiliary/draw/draw_private.h
+++ b/src/gallium/auxiliary/draw/draw_private.h
@@ -252,6 +252,7 @@ struct draw_context
struct pipe_viewport_state viewports[PIPE_MAX_VIEWPORTS];
boolean identity_viewport;
+ boolean bypass_viewport;
/** Vertex shader state */
struct {
@@ -478,6 +479,9 @@ void
draw_stats_clipper_primitives(struct draw_context *draw,
const struct draw_prim_info *prim_info);
+void draw_update_clip_flags(struct draw_context *draw);
+voi
Re: [Mesa-dev] [PATCH] st/mesa: copy sampler_array_size field when copying instructions
Reviewed-by: Ilia Mirkin
Ooops, I thought I had caught all of that :(
On Mon, Nov 17, 2014 at 4:42 PM, Brian Paul wrote:
> The sampler_array_size field was added by "mesa/st: add support for
> dynamic sampler offsets". But the field wasn't getting copied in
> the get_pixel_transfer_visitor() or get_bitmap_visitor() functions.
>
> The count_resources() function then didn't properly compute the
> glsl_to_tgsi_visitor::samplers_used bitmask. Then, we didn't declare
> all the sampler registers in st_translate_program(). Finally, we
> asserted when we tried to emit a tgsi ureg src register with File =
> TGSI_FILE_UNDEFINED.
>
> Add the missing assignments and some new assertions to catch the
> invalid register sooner.
>
> Cc: "10.3, 10.4"
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index c10ad75..8e91c4b 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -4022,6 +4022,7 @@ get_pixel_transfer_visitor(struct st_fragment_program
> *fp,
>
>newinst = v->emit(NULL, inst->op, inst->dst, src_regs[0], src_regs[1],
> src_regs[2]);
>newinst->tex_target = inst->tex_target;
> + newinst->sampler_array_size = inst->sampler_array_size;
> }
>
> /* Make modifications to fragment program info. */
> @@ -4101,6 +4102,7 @@ get_bitmap_visitor(struct st_fragment_program *fp,
>
>newinst = v->emit(NULL, inst->op, inst->dst, src_regs[0], src_regs[1],
> src_regs[2]);
>newinst->tex_target = inst->tex_target;
> + newinst->sampler_array_size = inst->sampler_array_size;
> }
>
> /* Make modifications to fragment program info. */
> @@ -4524,8 +4526,10 @@ compile_tgsi_instruction(struct st_translate *t,
> inst->saturate,
> clamp_dst_color_output);
>
> - for (i = 0; i < num_src; i++)
> + for (i = 0; i < num_src; i++) {
> + assert(inst->src[i].file != PROGRAM_UNDEFINED);
>src[i] = translate_src(t, &inst->src[i]);
> + }
>
> switch(inst->op) {
> case TGSI_OPCODE_BGNLOOP:
> @@ -4555,6 +4559,7 @@ compile_tgsi_instruction(struct st_translate *t,
> case TGSI_OPCODE_TG4:
> case TGSI_OPCODE_LODQ:
>src[num_src] = t->samplers[inst->sampler.index];
> + assert(src[num_src].File != TGSI_FILE_NULL);
>if (inst->sampler.reladdr)
> src[num_src] =
> ureg_src_indirect(src[num_src], ureg_src(t->address[2]));
> --
> 1.7.10.4
>
> ___
> 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] Mesa 10.3.4 candidate
I plan on checking in the multi-layer clear in the presence of scissor/color mask fix today or tomorrow, which should fix things for llvmpipe and nouveau. IMHO it'd be worth pulling that one in as well. It's not in yet, but just a heads-up. [Or were you planning on re-pulling on Wed?] On Mon, Nov 17, 2014 at 3:43 PM, Emil Velikov wrote: > Hello all, > > As you may have noticed there are only three commits since 10.3.3, which > imho are quite serious of people hitting those issues. > Thus I do plan on releasing 10.3.4 this Friday. > > The usual summary with testing & stats will be out on Wednesday, as I > would like to see if we'll have any additional patches for 10.3.4. > > As always if you have any comments, suggestions and/or objections, don't > be shy to speak up. > > Thanks > Emil > ___ > 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 v3 0/9] Gallium Nine
On 17/11/14 20:05, Emil Velikov wrote: > Henri, > > Considering the interface note able, would you say that any new > implementation towards handling D3D9 in wine is acceptable ? Please note > that I'm not talking about improving the existing one be that via GL > extensions or otherwise. > > How about if such an implementation is disabled by default in the build, > and people have to explicitly opt to (via regedit) use it ? A one that > falls back to wine, when it does not work (missing driver or otherwise) > and does not hinder your d3d10/d3d11 efforts ? > > If you're concerned about it's maintenance, I'm pretty sure that one of > the guys can step in. If it's about wine <> mesa(nine) interface I would > assume that the guys would love to hear your feedback (within reason of > course). > > Lastly let's point out that there is a reason why we keep on talking > about this - significant performance improvement [1] [2]. One that > surpasses wine+CSMT and in some cases even the official/binary drivers > on top of it. > In case the above came as me being smart/cocky/disrespectful - it's meant to say (amongst other things): - If there is something we can do to improve things, please keep us in the loop. - People do not know the wine internals as you do, so any feedback and you can provide about a reasonable interface is greatly appreciated. Taking into account the whole "we cannot really export gallium" of course. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXT/ARB direct state access extensions
+Laura. This thread is about you. On Sun 16 Nov 2014, Gustaw Smolarczyk wrote: Ok. It would be helpful to note the progress in the docs/GL3.txt file. The overview of ARB_dsa summarizes the difference between it and the EXT variant, so I understand the undesirability of implementing EXT_dsa. Gustaw 2014-11-16 12:07 GMT+01:00 Kenneth Graunke : On Saturday, November 15, 2014 10:42:47 PM Gustaw Smolarczyk wrote: Hello all, I would like to ask what is the status of DSA (direct state access) extensions in mesa. If I understand correctly, there was a GSoC project by Dylan Noblesmith and there currently is a dsa branch in mesa repo, but it's not actively worked on at the moment. Is there any particular reason for not mainlining this other than there being not enough interest in it? Or was the code not ready for inclusion? Since the GL 4.5 includes the DSA extension, it would be nice to support it in mesa. It also provides an easier way to use OpenGL and could decrease API call count. Regards, Gustaw Laura Ekstrand is currently working on implementing ARB_direct_state_access. I suspect it'll be part of the 10.5 release. Generally, people didn't seem too interested in supporting the older EXT_direct_state_access extension, claiming it was a bit ill-defined, and were generally unhappy with all the legacy interactions. Everybody's on board for the ARB version, but it looks a fair bit different than the older EXT one that's partially implemented on the "dsa" branch. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g/cayman: fix integer multiplication output overwrite
From: Dave Airlie
This fixes
tests/spec/glsl-1.10/execution/fs-op-assign-mult-ivec2-ivec2-overwrite.shader_test.
Reported-by: ghallberg on irc
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index aab4215..02efc92 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2729,6 +2729,9 @@ static int cayman_mul_int_instr(struct r600_shader_ctx
*ctx)
int i, j, k, r;
struct r600_bytecode_alu alu;
int last_slot = (inst->Dst[0].Register.WriteMask & 0x8) ? 4 : 3;
+ int t1 = ctx->temp_reg;
+ int lasti = tgsi_last_instruction(inst->Dst[0].Register.WriteMask);
+
for (k = 0; k < last_slot; k++) {
if (!(inst->Dst[0].Register.WriteMask & (1 << k)))
continue;
@@ -2739,7 +2742,8 @@ static int cayman_mul_int_instr(struct r600_shader_ctx
*ctx)
for (j = 0; j < inst->Instruction.NumSrcRegs; j++) {
r600_bytecode_src(&alu.src[j], &ctx->src[j], k);
}
- tgsi_dst(ctx, &inst->Dst[0], i, &alu.dst);
+ alu.dst.sel = t1;
+ alu.dst.chan = i;
alu.dst.write = (i == k);
if (i == 3)
alu.last = 1;
@@ -2748,6 +2752,23 @@ static int cayman_mul_int_instr(struct r600_shader_ctx
*ctx)
return r;
}
}
+
+ for (i = 0 ; i < last_slot; i++) {
+ if (!(inst->Dst[0].Register.WriteMask & (1 << i)))
+ continue;
+ memset(&alu, 0, sizeof(struct r600_bytecode_alu));
+ alu.op = ALU_OP1_MOV;
+ alu.src[0].sel = t1;
+ alu.src[0].chan = i;
+ tgsi_dst(ctx, &inst->Dst[0], i, &alu.dst);
+ alu.dst.write = 1;
+ if (i == lasti)
+ alu.last = 1;
+ r = r600_bytecode_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+ }
+
return 0;
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g/cayman: fix integer multiplication output overwrite (v2)
From: Dave Airlie
This fixes
tests/spec/glsl-1.10/execution/fs-op-assign-mult-ivec2-ivec2-overwrite.shader_test.
Reported-by: ghallberg on irc
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index aab4215..ac26d77 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2728,8 +2728,10 @@ static int cayman_mul_int_instr(struct r600_shader_ctx
*ctx)
struct tgsi_full_instruction *inst =
&ctx->parse.FullToken.FullInstruction;
int i, j, k, r;
struct r600_bytecode_alu alu;
- int last_slot = (inst->Dst[0].Register.WriteMask & 0x8) ? 4 : 3;
- for (k = 0; k < last_slot; k++) {
+ int lasti = tgsi_last_instruction(inst->Dst[0].Register.WriteMask);
+ int t1 = ctx->temp_reg;
+
+ for (k = 0; k <= lasti; k++) {
if (!(inst->Dst[0].Register.WriteMask & (1 << k)))
continue;
@@ -2739,7 +2741,8 @@ static int cayman_mul_int_instr(struct r600_shader_ctx
*ctx)
for (j = 0; j < inst->Instruction.NumSrcRegs; j++) {
r600_bytecode_src(&alu.src[j], &ctx->src[j], k);
}
- tgsi_dst(ctx, &inst->Dst[0], i, &alu.dst);
+ alu.dst.sel = t1;
+ alu.dst.chan = i;
alu.dst.write = (i == k);
if (i == 3)
alu.last = 1;
@@ -2748,6 +2751,23 @@ static int cayman_mul_int_instr(struct r600_shader_ctx
*ctx)
return r;
}
}
+
+ for (i = 0 ; i <= lasti; i++) {
+ if (!(inst->Dst[0].Register.WriteMask & (1 << i)))
+ continue;
+ memset(&alu, 0, sizeof(struct r600_bytecode_alu));
+ alu.op = ALU_OP1_MOV;
+ alu.src[0].sel = t1;
+ alu.src[0].chan = i;
+ tgsi_dst(ctx, &inst->Dst[0], i, &alu.dst);
+ alu.dst.write = 1;
+ if (i == lasti)
+ alu.last = 1;
+ r = r600_bytecode_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+ }
+
return 0;
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.3.4 candidate
I will check for patches tomorrow and Wed morning. Then I'll throw piglit in the mix and let it do it's thing :) On 17/11/14 22:00, Ilia Mirkin wrote: > I plan on checking in the multi-layer clear in the presence of > scissor/color mask fix today or tomorrow, which should fix things for > llvmpipe and nouveau. IMHO it'd be worth pulling that one in as well. > It's not in yet, but just a heads-up. [Or were you planning on > re-pulling on Wed?] > > On Mon, Nov 17, 2014 at 3:43 PM, Emil Velikov > wrote: >> Hello all, >> >> As you may have noticed there are only three commits since 10.3.3, which >> imho are quite serious of people hitting those issues. >> Thus I do plan on releasing 10.3.4 this Friday. >> >> The usual summary with testing & stats will be out on Wednesday, as I >> would like to see if we'll have any additional patches for 10.3.4. >> >> As always if you have any comments, suggestions and/or objections, don't >> be shy to speak up. >> >> Thanks >> Emil >> ___ >> 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] r600g/cayman: fix integer multiplication output overwrite
On Tue, 18 Nov 2014 00:56:38 +0100, Dave Airlie wrote:
From: Dave Airlie
This fixes
tests/spec/glsl-1.10/execution/fs-op-assign-mult-ivec2-ivec2-overwrite.shader_test.
Reported-by: ghallberg on irc
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index aab4215..02efc92 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2729,6 +2729,9 @@ static int cayman_mul_int_instr(struct
r600_shader_ctx *ctx)
int i, j, k, r;
struct r600_bytecode_alu alu;
int last_slot = (inst->Dst[0].Register.WriteMask & 0x8) ? 4 : 3;
+ int t1 = ctx->temp_reg;
+ int lasti = tgsi_last_instruction(inst->Dst[0].Register.WriteMask);
+
for (k = 0; k < last_slot; k++) {
if (!(inst->Dst[0].Register.WriteMask & (1 << k)))
continue;
@@ -2739,7 +2742,8 @@ static int cayman_mul_int_instr(struct
r600_shader_ctx *ctx)
for (j = 0; j < inst->Instruction.NumSrcRegs; j++) {
r600_bytecode_src(&alu.src[j], &ctx->src[j], k);
}
- tgsi_dst(ctx, &inst->Dst[0], i, &alu.dst);
+ alu.dst.sel = t1;
+ alu.dst.chan = i;
alu.dst.write = (i == k);
if (i == 3)
alu.last = 1;
@@ -2748,6 +2752,23 @@ static int cayman_mul_int_instr(struct
r600_shader_ctx *ctx)
return r;
}
}
+
+ for (i = 0 ; i < last_slot; i++) {
+ if (!(inst->Dst[0].Register.WriteMask & (1 << i)))
+ continue;
+ memset(&alu, 0, sizeof(struct r600_bytecode_alu));
+ alu.op = ALU_OP1_MOV;
+ alu.src[0].sel = t1;
+ alu.src[0].chan = i;
+ tgsi_dst(ctx, &inst->Dst[0], i, &alu.dst);
+ alu.dst.write = 1;
+ if (i == lasti)
+ alu.last = 1;
+ r = r600_bytecode_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+ }
+
return 0;
}
Trivial nit: last_slot is no longer needed and can be removed.
With a bit of luck it will also fix
https://bugs.freedesktop.org/show_bug.cgi?id=85376
Reviewed-by: Glenn Kennard
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On 14/11/14 14:39, Emil Velikov wrote: > Hello all, > > This is an old question that I had laying around - why doesn't mesa use > a more conventional numbering for the development/rc releases ? > > Eg. > mesa 10.4.0-rc1 -> 10.3.99.901 > mesa 10.4.0-rc2 -> 10.3.99.902 > ... > mesa 10.4.0 -> 10.4.0 > mesa 10.4.1-rc1 -> 10.4.0.901 > ... you get the idea. > > Afaics most freedesktop project use it plus a big hunk of gnome. > > Are there any objections if I move to the above format starting with > mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, > and based on it I'll tag the first RC. > > The plan is to still keep the branch point later on today, but to push > the tag on Monday. > OK so it seems that we have people concerned that this may cause issues/lack of consistency within mesa, a few people with neutral option and no strong supporters on the topic :'( The people have spoken - things are staying as is. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g/cayman: fix texture gather tests
From: Dave Airlie
It appears on cayman the TG4 outputs were reordered.
This fixes a lot of piglit tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 4c6ae45..709fcd7 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -5763,11 +5763,18 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
int8_t texture_component_select = ctx->literals[4 *
inst->Src[1].Register.Index + inst->Src[1].Register.SwizzleX];
tex.inst_mod = texture_component_select;
+ if (ctx->bc->chip_class == CAYMAN) {
/* GATHER4 result order is different from TGSI TG4 */
- tex.dst_sel_x = (inst->Dst[0].Register.WriteMask & 2) ? 1 : 7;
- tex.dst_sel_y = (inst->Dst[0].Register.WriteMask & 4) ? 2 : 7;
- tex.dst_sel_z = (inst->Dst[0].Register.WriteMask & 1) ? 0 : 7;
- tex.dst_sel_w = (inst->Dst[0].Register.WriteMask & 8) ? 3 : 7;
+ tex.dst_sel_x = (inst->Dst[0].Register.WriteMask & 2) ?
0 : 7;
+ tex.dst_sel_y = (inst->Dst[0].Register.WriteMask & 4) ?
1 : 7;
+ tex.dst_sel_z = (inst->Dst[0].Register.WriteMask & 1) ?
2 : 7;
+ tex.dst_sel_w = (inst->Dst[0].Register.WriteMask & 8) ?
3 : 7;
+ } else {
+ tex.dst_sel_x = (inst->Dst[0].Register.WriteMask & 2) ?
1 : 7;
+ tex.dst_sel_y = (inst->Dst[0].Register.WriteMask & 4) ?
2 : 7;
+ tex.dst_sel_z = (inst->Dst[0].Register.WriteMask & 1) ?
0 : 7;
+ tex.dst_sel_w = (inst->Dst[0].Register.WriteMask & 8) ?
3 : 7;
+ }
}
else if (inst->Instruction.Opcode == TGSI_OPCODE_LODQ) {
tex.dst_sel_x = (inst->Dst[0].Register.WriteMask & 2) ? 1 : 7;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g/cayman: hande empty vertex shaders
From: Dave Airlie
Some of the geom shader tests produce an empty vertex shader,
on cayman we'd crash in the finaliser because last_cf was NULL.
cayman doesn't need the NOP workaround, so if the code arrives
here with no last_cf, just emit an END.
fixes crashes in a bunch of piglit geom shader tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/sb/sb_bc_finalize.cpp | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
b/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
index 5c22f96..f0849ca 100644
--- a/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
+++ b/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
@@ -83,14 +83,18 @@ int bc_finalizer::run() {
last_cf = c;
}
- if (last_cf->bc.op_ptr->flags & CF_ALU) {
+ if (!ctx.is_cayman() && last_cf->bc.op_ptr->flags & CF_ALU) {
last_cf = sh.create_cf(CF_OP_NOP);
sh.root->push_back(last_cf);
}
- if (ctx.is_cayman())
- last_cf->insert_after(sh.create_cf(CF_OP_CF_END));
- else
+ if (ctx.is_cayman()) {
+ if (!last_cf) {
+ cf_node *c = sh.create_cf(CF_OP_CF_END);
+ sh.root->push_back(c);
+ } else
+ last_cf->insert_after(sh.create_cf(CF_OP_CF_END));
+ } else
last_cf->bc.end_of_program = 1;
for (unsigned t = EXP_PIXEL; t < EXP_TYPE_COUNT; ++t) {
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/cayman: fix texture gather tests
On Tue, 18 Nov 2014 01:57:13 +0100, Dave Airlie wrote:
From: Dave Airlie
It appears on cayman the TG4 outputs were reordered.
This fixes a lot of piglit tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 4c6ae45..709fcd7 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -5763,11 +5763,18 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
int8_t texture_component_select = ctx->literals[4 *
inst->Src[1].Register.Index + inst->Src[1].Register.SwizzleX];
tex.inst_mod = texture_component_select;
+ if (ctx->bc->chip_class == CAYMAN) {
/* GATHER4 result order is different from TGSI TG4 */
- tex.dst_sel_x = (inst->Dst[0].Register.WriteMask & 2) ? 1 : 7;
- tex.dst_sel_y = (inst->Dst[0].Register.WriteMask & 4) ? 2 : 7;
- tex.dst_sel_z = (inst->Dst[0].Register.WriteMask & 1) ? 0 : 7;
- tex.dst_sel_w = (inst->Dst[0].Register.WriteMask & 8) ? 3 : 7;
+ tex.dst_sel_x = (inst->Dst[0].Register.WriteMask & 2) ?
0 : 7;
+ tex.dst_sel_y = (inst->Dst[0].Register.WriteMask & 4) ?
1 : 7;
+ tex.dst_sel_z = (inst->Dst[0].Register.WriteMask & 1) ?
2 : 7;
+ tex.dst_sel_w = (inst->Dst[0].Register.WriteMask & 8) ?
3 : 7;
+ } else {
+ tex.dst_sel_x = (inst->Dst[0].Register.WriteMask & 2) ?
1 : 7;
+ tex.dst_sel_y = (inst->Dst[0].Register.WriteMask & 4) ?
2 : 7;
+ tex.dst_sel_z = (inst->Dst[0].Register.WriteMask & 1) ?
0 : 7;
+ tex.dst_sel_w = (inst->Dst[0].Register.WriteMask & 8) ?
3 : 7;
+ }
}
else if (inst->Instruction.Opcode == TGSI_OPCODE_LODQ) {
tex.dst_sel_x = (inst->Dst[0].Register.WriteMask & 2) ? 1 : 7;
Gotta permute those tex op bit encodings between hardware generations or
they go stale...
Reviewed-by: Glenn Kennard
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/cayman: hande empty vertex shaders
On Tue, 18 Nov 2014 02:23:51 +0100, Dave Airlie wrote:
From: Dave Airlie
Some of the geom shader tests produce an empty vertex shader,
on cayman we'd crash in the finaliser because last_cf was NULL.
cayman doesn't need the NOP workaround, so if the code arrives
here with no last_cf, just emit an END.
fixes crashes in a bunch of piglit geom shader tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/sb/sb_bc_finalize.cpp | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
b/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
index 5c22f96..f0849ca 100644
--- a/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
+++ b/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
@@ -83,14 +83,18 @@ int bc_finalizer::run() {
last_cf = c;
}
- if (last_cf->bc.op_ptr->flags & CF_ALU) {
+ if (!ctx.is_cayman() && last_cf->bc.op_ptr->flags & CF_ALU) {
last_cf = sh.create_cf(CF_OP_NOP);
sh.root->push_back(last_cf);
}
- if (ctx.is_cayman())
- last_cf->insert_after(sh.create_cf(CF_OP_CF_END));
- else
+ if (ctx.is_cayman()) {
+ if (!last_cf) {
+ cf_node *c = sh.create_cf(CF_OP_CF_END);
+ sh.root->push_back(c);
+ } else
+ last_cf->insert_after(sh.create_cf(CF_OP_CF_END));
+ } else
last_cf->bc.end_of_program = 1;
for (unsigned t = EXP_PIXEL; t < EXP_TYPE_COUNT; ++t) {
Reviewed-by: Glenn Kennard
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 0/8] Gallium Nine
On 17/11/14 15:58, Axel Davy wrote: > Hi, > > Here is last (4th) iteration of Gallium Nine patches. > > We have integrated the new feedback we have got and hope > the status of the serie is good enough now for merge. > Just added the remaining r-b/acked-by tags and pushed it to master. Guys take care of st/nine :) Cheers Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] r600g/compute: Don't leak cbufs in compute state
On 17.11.2014 23:30, Aaron Watry wrote:
On Mon, Nov 17, 2014 at 1:45 AM, Michel Dänzer wrote:
On 14.11.2014 19:37, Marek Olšák wrote:
surface_destroy should never be called directly, because surfaces have
a reference counter. For unreferencing resources, use
pipe_surface_reference(&pointer, NULL). It will call surface_destroy
if needed.
Indeed, if this was the right place for this, it could be done both
easier and more robustly:
for (int i = 0; i < fb_state->nr_cbufs; i++)
pipe_surface_reference(&fb_state->cbufs[i], NULL);
Yeah, you're right about that. After your (Michel/Marek) replies, I
had come to the same conclusion about simplifying things. I'm having
*fun* deciding where the proper place to put this in the evergreen
code is. We end up calling evergreen_set_rat from multiple places,
which is where the surfaces are created, and then we keep a list with
a set count... and the individual surfaces themselves get freed as
their reference counts change. In theory, they all get
referenced/freed at the same point, but there's no guarantees that I
can see.
The first logical place that I saw to put the de-reference is in
evergreen_set_global_binding and the matching
create/delete_compute_state functions.
AFAICT it indeed needs to be handled in evergreen_set_compute_resources
and evergreen_set_global_binding. Does the attached patch work?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
>From 2ee9c0c435405df7382363ae8f276cd3ce4f8c6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
Date: Tue, 18 Nov 2014 11:46:22 +0900
Subject: [PATCH] r600g/compute: Fix cbuf leaks
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/r600/evergreen_compute.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c b/src/gallium/drivers/r600/evergreen_compute.c
index 90fdd79..64c3cee 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -127,6 +127,7 @@ static void evergreen_set_rat(
rat_templ.u.tex.last_layer = 0;
/* Add the RAT the list of color buffers */
+ pipe_surface_reference(&pipe->ctx->framebuffer.state.cbufs[id], NULL);
pipe->ctx->framebuffer.state.cbufs[id] = pipe->ctx->b.b.create_surface(
(struct pipe_context *)pipe->ctx,
(struct pipe_resource *)bo, &rat_templ);
@@ -627,11 +628,16 @@ static void evergreen_set_compute_resources(struct pipe_context * ctx_,
{
struct r600_context *ctx = (struct r600_context *)ctx_;
struct r600_surface **resources = (struct r600_surface **)surfaces;
+ unsigned i;
COMPUTE_DBG(ctx->screen, "*** evergreen_set_compute_resources: start = %u count = %u\n",
start, count);
- for (unsigned i = 0; i < count; i++) {
+ /* Unreference unused surfaces */
+ for (i = count + 1; i < ctx->framebuffer.state.nr_cbufs; i++)
+ pipe_surface_reference(&ctx->framebuffer.state.cbufs[i], NULL);
+
+ for (i = 0; i < count; i++) {
/* The First two vertex buffers are reserved for parameters and
* global buffers. */
unsigned vtx_id = 2 + i;
@@ -651,6 +657,9 @@ static void evergreen_set_compute_resources(struct pipe_context * ctx_,
evergreen_cs_set_vertex_buffer(ctx, vtx_id,
buffer->chunk->start_in_dw * 4,
resources[i]->base.texture);
+ } else {
+ pipe_surface_reference(&ctx->framebuffer.state.cbufs[i+1],
+ NULL);
}
}
}
@@ -688,10 +697,11 @@ static void evergreen_set_global_binding(
COMPUTE_DBG(ctx->screen, "*** evergreen_set_global_binding first = %u n = %u\n",
first, n);
- if (!resources) {
- /* XXX: Unset */
+ /* Unreference previous resource */
+ pipe_surface_reference(&ctx->framebuffer.state.cbufs[0], NULL);
+
+ if (!resources)
return;
- }
/* We mark these items for promotion to the pool if they
* aren't already there */
@@ -702,10 +712,8 @@ static void evergreen_set_global_binding(
buffers[i]->chunk->status |= ITEM_FOR_PROMOTING;
}
- if (compute_memory_finalize_pending(pool, ctx_) == -1) {
- /* XXX: Unset */
+ if (compute_memory_finalize_pending(pool, ctx_) == -1)
return;
- }
for (i = first; i < first + n; i++)
{
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 7/8] nine: Add drirc options (v2)
On 18.11.2014 00:58, Axel Davy wrote: Implements vblank_mode and throttling, which allows us change default ratio between framerate and input lag. Signed-off-by: David Heidelberg Signed-off-by: Axel Davy Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 10.4.0 release candidate 1
Mesa 10.4.0 release candidate 1 is now available for testing. The current plan is to have an additional release candidate each Friday until the eventual 10.4.0 release on Friday, Dec 5th. The tag in the git repository for Mesa 10.4.0-rc1 is 'mesa-10.4.0-rc1'. As a reminder, with the 10.4 branch now created, patches nominated with: CC: will now be candidates only for the new 10.4 branch. To nominate patches for the older 10.3 branch as well, please use: CC: "10.3 10.4" The expectation is that the 10.3 branch will remain alive with bi-weekly releases until after 10.4.1 release. Mesa 10.4.0 release candidate 1 is available for download from ftp://freedesktop.org/pub/mesa/10.4.0/ sha256sums: 0f598943dfe00de1e9eab6f84402a4794716351af74d872eee4f294daceaad51 MesaLib-10.4.0-rc1.tar.gz a84937b27c4169d59af0750969920ce4d2638652d3ff088b9626c8b469340e5a MesaLib-10.4.0-rc1.tar.bz2 2e162445713f82bf3242a128ca73c967a495a8db05d52bbfb253634bcc346989 MesaLib-10.4.0-rc1.zip I have verified building from the .tar.bz2 file by doing: tar xjf MesaLib-10.4.0-rc1.tar.bz2 cd Mesa-10.4.0-rc1 ./configure --enable-gallium-llvm make -j6 make -j6 install A worthy mention: I have decided to pick the gallium-nine work, for the 10.4 branch considering how well it's isolated from everything else. Not to mention that now it has a maintainer :) -Emil signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: support per-sample gl_FragCoord
On 18.11.2014 06:42, Marek Olšák wrote: From: Marek Olšák Cc: 10.4 Both patches are Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50/ir: saturate FRC result to avoid completely bogus values
For values above integer accuracy in floats, val - floor(val) might actually produce a value greater than 1. For such large floats, it's reasonable to be imprecise, but it's unreasonable for FRC to return a value that is not between 0 and 1. Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index 41b91e8..e5b767f 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -2512,7 +2512,8 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) src0 = fetchSrc(0, c); val0 = getScratch(); mkOp1(OP_FLOOR, TYPE_F32, val0, src0); - mkOp2(OP_SUB, TYPE_F32, dst0[c], src0, val0); + mkOp2(OP_SUB, TYPE_F32, val0, src0, val0); + mkOp1(OP_SAT, TYPE_F32, dst0[c], val0); } break; case TGSI_OPCODE_ROUND: -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: geom shaders: always load texture src regs from inputs
From: Dave Airlie Otherwise we seem to lose the split_gs_inputs and try and pull from an uninitialised register. fixes 9 texelFetch geom shader tests. Signed-off-by: Dave Airlie --- src/gallium/drivers/r600/r600_shader.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/r600/r600_shader.c b/src/gallium/drivers/r600/r600_shader.c index 709fcd7..ab2a838 100644 --- a/src/gallium/drivers/r600/r600_shader.c +++ b/src/gallium/drivers/r600/r600_shader.c @@ -4919,7 +4919,8 @@ static inline boolean tgsi_tex_src_requires_loading(struct r600_shader_ctx *ctx, return (inst->Src[index].Register.File != TGSI_FILE_TEMPORARY && inst->Src[index].Register.File != TGSI_FILE_INPUT && inst->Src[index].Register.File != TGSI_FILE_OUTPUT) || - ctx->src[index].neg || ctx->src[index].abs; + ctx->src[index].neg || ctx->src[index].abs || + (inst->Src[index].Register.File == TGSI_FILE_INPUT && ctx->type == TGSI_PROCESSOR_GEOMETRY); } static inline unsigned tgsi_tex_get_src_gpr(struct r600_shader_ctx *ctx, -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: limit texture offset application to specific types
From: Dave Airlie
For 1D and 2D arrays we don't want the other coordinates being
offset and affecting where we sample. I wrote this patch 6 months
ago but lost it.
This fixes at least
./bin/tex-miplevel-selection textureOffset 1DArray
./bin/tex-miplevel-selection textureOffset 2DArray
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index ab2a838..f889399 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -5536,8 +5536,11 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
}
} else {
offset_x = ctx->literals[4 * inst->TexOffsets[0].Index
+ inst->TexOffsets[0].SwizzleX] << 1;
- offset_y = ctx->literals[4 * inst->TexOffsets[0].Index
+ inst->TexOffsets[0].SwizzleY] << 1;
+ if (inst->Texture.Texture != TGSI_TEXTURE_1D &&
inst->Texture.Texture != TGSI_TEXTURE_1D_ARRAY) {
+ offset_y = ctx->literals[4 *
inst->TexOffsets[0].Index + inst->TexOffsets[0].SwizzleY] << 1;
+ if (inst->Texture.Texture != TGSI_TEXTURE_2D &&
inst->Texture.Texture != TGSI_TEXTURE_2D_ARRAY && inst->Texture.Texture !=
TGSI_TEXTURE_RECT)
offset_z = ctx->literals[4 * inst->TexOffsets[0].Index
+ inst->TexOffsets[0].SwizzleZ] << 1;
+ }
}
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: limit texture offset application to specific types (v2)
From: Dave Airlie
For 1D and 2D arrays we don't want the other coordinates being
offset and affecting where we sample. I wrote this patch 6 months
ago but lost it.
Fixes:
./bin/tex-miplevel-selection textureLodOffset 1DArray
./bin/tex-miplevel-selection textureLodOffset 2DArray
./bin/tex-miplevel-selection textureOffset 1DArray
./bin/tex-miplevel-selection textureOffset 1DArrayShadow
./bin/tex-miplevel-selection textureOffset 2DArray
./bin/tex-miplevel-selection textureOffset(bias) 1DArray
./bin/tex-miplevel-selection textureOffset(bias) 2DArray
v2: rewrite to handle more cases and be consistent with code
above.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index ab2a838..76daf2c 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -5535,9 +5535,24 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
/* texture offsets do not apply to other
texture targets */
}
} else {
- offset_x = ctx->literals[4 * inst->TexOffsets[0].Index
+ inst->TexOffsets[0].SwizzleX] << 1;
- offset_y = ctx->literals[4 * inst->TexOffsets[0].Index
+ inst->TexOffsets[0].SwizzleY] << 1;
- offset_z = ctx->literals[4 * inst->TexOffsets[0].Index
+ inst->TexOffsets[0].SwizzleZ] << 1;
+ switch (inst->Texture.Texture) {
+ case TGSI_TEXTURE_3D:
+ offset_z = ctx->literals[4 *
inst->TexOffsets[0].Index + inst->TexOffsets[0].SwizzleZ] << 1;
+ /* fallthrough */
+ case TGSI_TEXTURE_2D:
+ case TGSI_TEXTURE_SHADOW2D:
+ case TGSI_TEXTURE_RECT:
+ case TGSI_TEXTURE_SHADOWRECT:
+ case TGSI_TEXTURE_2D_ARRAY:
+ case TGSI_TEXTURE_SHADOW2D_ARRAY:
+ offset_y = ctx->literals[4 *
inst->TexOffsets[0].Index + inst->TexOffsets[0].SwizzleY] << 1;
+ /* fallthrough */
+ case TGSI_TEXTURE_1D:
+ case TGSI_TEXTURE_SHADOW1D:
+ case TGSI_TEXTURE_1D_ARRAY:
+ case TGSI_TEXTURE_SHADOW1D_ARRAY:
+ offset_x = ctx->literals[4 *
inst->TexOffsets[0].Index + inst->TexOffsets[0].SwizzleX] << 1;
+ }
}
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.3.4 candidate
On 18.11.2014 05:43, Emil Velikov wrote:
Hello all,
As you may have noticed there are only three commits since 10.3.3, which
imho are quite serious of people hitting those issues.
Thus I do plan on releasing 10.3.4 this Friday.
The usual summary with testing & stats will be out on Wednesday, as I
would like to see if we'll have any additional patches for 10.3.4.
As always if you have any comments, suggestions and/or objections, don't
be shy to speak up.
Please backport my commit ae4536b4f71cbe76230ea7edc7eb4d6041e651b4
('radeonsi: Disable asynchronous DMA except for PIPE_BUFFER') to the
10.3 and 10.4 branches.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
