Re: [Mesa-dev] [PATCH 3/4] auxiliary: ship all files in the distribution tarball
> 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 . Spite of .cpp extension, it would be better to think of this a a code generation script. Jose From: mesa-dev on behalf of Emil Velikov Sent: 14 October 2014 17:44 To: mesa-dev@lists.freedesktop.org Cc: emil.l.veli...@gmail.com Subject: [Mesa-dev] [PATCH 3/4] auxiliary: ship all files in the distribution tarball - Add all headers into Makefile.sources - Don't forget the target-helpers - Add the python scripts & the formats table/list (csv) - Temporary add vl/vl_winsys_dri.c to EXTRA_DIST until we rework the way VL is build. - Add the following to EXTRA_DIST - they are included via the generated u_indices_gen.c thus we should not add them to *SOURCES. indices/u_indices.c indices/u_unfilled_indices.c XXX: Should we nuke gallivm/f.cpp ? It seems that no-one is using it. Signed-off-by: Emil Velikov --- src/gallium/auxiliary/Makefile.am | 10 + src/gallium/auxiliary/Makefile.sources | 321 +++-- 2 files changed, 271 insertions(+), 60 deletions(-) diff --git a/src/gallium/auxiliary/Makefile.am b/src/gallium/auxiliary/Makefile.am index 4d8ba89..3688edc 100644 --- a/src/gallium/auxiliary/Makefile.am +++ b/src/gallium/auxiliary/Makefile.am @@ -46,3 +46,13 @@ indices/u_unfilled_gen.c: $(srcdir)/indices/u_unfilled_gen.py util/u_format_table.c: $(srcdir)/util/u_format_table.py $(srcdir)/util/u_format_pack.py $(srcdir)/util/u_format_parse.py $(srcdir)/util/u_format.csv $(AM_V_at)$(MKDIR_P) util $(AM_V_GEN) $(PYTHON2) $(srcdir)/util/u_format_table.py $(srcdir)/util/u_format.csv > $@ + +EXTRA_DIST = \ + indices/u_indices.c \ + indices/u_unfilled_indices.c \ + target-helpers \ + util/u_format.csv \ + util/u_format_pack.py \ + util/u_format_parse.py \ + util/u_format_table.py \ + vl/vl_winsys_dri.c diff --git a/src/gallium/auxiliary/Makefile.sources b/src/gallium/auxiliary/Makefile.sources index 58d8af7..de90549 100644 --- a/src/gallium/auxiliary/Makefile.sources +++ b/src/gallium/auxiliary/Makefile.sources @@ -1,11 +1,21 @@ C_SOURCES := \ cso_cache/cso_cache.c \ + cso_cache/cso_cache.h \ cso_cache/cso_context.c \ + cso_cache/cso_context.h \ cso_cache/cso_hash.c \ + cso_cache/cso_hash.h \ + draw/draw_cliptest_tmp.h \ draw/draw_context.c \ + draw/draw_context.h \ + draw/draw_decompose_tmp.h \ draw/draw_fs.c \ + draw/draw_fs.h \ draw/draw_gs.c \ + draw/draw_gs.h \ + draw/draw_gs_tmp.h \ draw/draw_pipe.c \ + draw/draw_pipe.h \ draw/draw_pipe_aaline.c \ draw/draw_pipe_aapoint.c \ draw/draw_pipe_clip.c \ @@ -22,141 +32,305 @@ C_SOURCES := \ draw/draw_pipe_wide_line.c \ draw/draw_pipe_wide_point.c \ draw/draw_prim_assembler.c \ + draw/draw_prim_assembler.h \ + draw/draw_prim_assembler_tmp.h \ + draw/draw_private.h \ draw/draw_pt.c \ + draw/draw_pt_decompose.h \ draw/draw_pt_emit.c \ draw/draw_pt_fetch.c \ draw/draw_pt_fetch_emit.c \ draw/draw_pt_fetch_shade_emit.c \ draw/draw_pt_fetch_shade_pipeline.c \ + draw/draw_pt.h \ draw/draw_pt_post_vs.c \ draw/draw_pt_so_emit.c \ draw/draw_pt_util.c \ draw/draw_pt_vsplit.c \ + draw/draw_pt_vsplit_tmp.h \ + draw/draw_so_emit_tmp.h \ + draw/draw_split_tmp.h \ + draw/draw_vbuf.h \ draw/draw_vertex.c \ + draw/draw_vertex.h \ draw/draw_vs.c \ draw/draw_vs_exec.c \ + draw/draw_vs.h \ draw/draw_vs_variant.c \ hud/font.c \ + hud/font.h \ hud/hud_context.c \ + hud/hud_context.h \ hud/hud_cpu.c \ + hud/hud_driver_query.c \ hud/hud_fps.c \ -hud/hud_driver_query.c \ + hud/hud_private.h \ + indices/u_indices.h \ + indices/u_indices_priv.h \ indices/u_primconvert.c \ + indices/u_primconvert.h \ + os/os_memory_aligned.h \ + os/os_memory_debug.h \ + os/os_memory.h \ + os/os_memory_stdc.h \ os/os_misc.c \ + os/os_misc.h \ + os/os_mman.h \ os/os_process.c \ + os/os_process.h \ + os/os_thread.h \ os/os_time.c \ + os/os_time.h \ pipebuffer/pb_buffer_fenced.c \ + pipebuffer/pb_buffer_fenced.h \ + pipebuffer/pb_buffer.h \ pipebuffer/pb_buffer_malloc.c \ pipebuffer/pb_bufmgr_alt.c \ pipebuffer/pb_bufmgr_cache.c \ pipebuffer/pb_bufmgr_debu
[Mesa-dev] [Bug 86330] lp_bld_debug.cpp:112: multiple definition of `raw_debug_ostream::write_impl(char const*, unsigned long)'
https://bugs.freedesktop.org/show_bug.cgi?id=86330 José Fonseca changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from José Fonseca --- Should be fixed now with 4784623b3ef8a8325d7b92c3365400f23bae63e0. I also fixed a problem building without llvm too. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] tinderbox build regression
Dear Dave, Dave Airlie wrote on 16.11.2014 06:20: > no idea but I'm picking Emil as the culprit! I've seen the same failure, but a more recent LLVM 3.6 fixed it for me. I can report LLVM SVN r222082 as working. Cheers, Kai 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] tinderbox build regression
Kai Wasserbäch wrote on 16.11.2014 11:49: > Dear Dave, > Dave Airlie wrote on 16.11.2014 06:20: >> no idea but I'm picking Emil as the culprit! > > I've seen the same failure, but a more recent LLVM 3.6 fixed it for me. I can > report LLVM SVN r222082 as working. Nah, sorry. I was wrong. You've seen bug 86330, I had a similar looking but different build failure, that was due to the LLVM version (see Tom Stellard's reversion of cd93d82ba9ec8cd8e4f54bbee16d7b47c542de71 in 0cae7ea2719a939cf91de03a1bfeeeca08ec98a4). Sorry for the noise. Cheers, Kai 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] EXT/ARB direct state access extensions
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 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
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
Acked by me. I didn't review the state tracker code, but at least I didn't notice anything wrong with the changes to the auxiliary modules, and I don't obecjt having this merged back in now that it is being actively maintained, Jose From: mesa-dev on behalf of Emil Velikov Sent: 14 November 2014 14:14 To: David Heidelberg; mesa-dev@lists.freedesktop.org Cc: emil.l.veli...@gmail.com Subject: Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine 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 > Gents, Can we get an acked-by/reviewed-by for this ? Would be a shame to torture David to keep rebasing this for another three months. Afaics he's already applied to commit access with the sole perpose to maintain the state-tracker. Thanks Emil P.S. Patches 3 and 6 have minor comments to address. I don't mind if patch 6 is resolved after the merge. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=eN-BbuqoGCTkisd-4qwlqZT03Gccr_3oPmVy9RTe370&s=n4htOYU6cyo0-OAtl4G2eksxLIwAxGWHvtK16W4TdRU&e= ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Require glproto >= 1.4.13 for X11.
Looks good. Thanks.
Jose
From: mesa-dev on behalf of Vinson Lee
Sent: 15 November 2014 22:16
To: mesa-dev@lists.freedesktop.org
Cc: 10.4
Subject: [Mesa-dev] [PATCH] scons: Require glproto >= 1.4.13 for X11.
GLXBadProfileARB and X_GLXCreateContextAtrribsARB require glproto >=
1.4.13. These symbols were added in commit
d5d41112cbccd9301500e8e023be77eb9cb622cd "st/xlib: Generate errors as
specified."
Signed-off-by: Vinson Lee
Cc: "10.4"
---
scons/gallium.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scons/gallium.py b/scons/gallium.py
index e3786d2..4df6e1a 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -621,7 +621,7 @@ def generate(env):
env.Tool('custom')
createInstallMethods(env)
-env.PkgCheckModules('X11', ['x11', 'xext', 'xdamage', 'xfixes'])
+env.PkgCheckModules('X11', ['x11', 'xext', 'xdamage', 'xfixes', 'glproto
>= 1.4.13'])
env.PkgCheckModules('XCB', ['x11-xcb', 'xcb-glx >= 1.8.1', 'xcb-dri2 >=
1.8'])
env.PkgCheckModules('XF86VIDMODE', ['xxf86vm'])
env.PkgCheckModules('DRM', ['libdrm >= 2.4.38'])
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=DYyvv_6zghheqtHtM3KQ9ZFTgp-6v_NmlTWHVLg6bto&s=whjXi2-oWUwJiqecPjc1qPz6og_HwUydj1xZFvmaZM4&e=
___
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
> Fun fact -- llvmpipe also needs this.
I think this is because this functionality was developed with D3D10 in mind,
and
http://msdn.microsoft.com/en-gb/library/windows/desktop/bb509647.aspx
states that SV_RenderTargetArrayIndex "an be written from the geometry shader
and read by the pixel shader."
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.
Jose
From: mesa-dev on behalf of Ilia
Mirkin
Sent: 15 November 2014 21:20
To: mesa-dev@lists.freedesktop.org
Cc: 10.3 10.4
Subject: Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad
when no vs_layer
On Sat, Nov 15, 2014 at 1:38 PM, Ilia Mirkin wrote:
> Not all drivers can set gl_Layer from VS. Add a fallback that passes the
> instance id from VS to GS, and then uses the GS to set the layer.
>
> Tested by adding
>
> quad_buffers |= clear_buffers;
> clear_buffers = 0;
>
> to the st_Clear logic, and forcing set_vertex_shader_layered in all
> cases. No piglit regressions (on piglits with 'clear' in the name).
>
> Signed-off-by: Ilia Mirkin
> Cc: "10.3 10.4"
> ---
>
> No explicit piglit test hits this path without the above hacks, so it went
> under the radar for a long time. I tested this on nvc0 with the above hacks,
> and double-checked that without them, things still worked.
Fun fact -- llvmpipe also needs this.
>
> src/gallium/auxiliary/util/u_simple_shaders.c | 70
> +++
> src/gallium/auxiliary/util/u_simple_shaders.h | 6 +++
> src/mesa/state_tracker/st_cb_clear.c | 25 --
> src/mesa/state_tracker/st_context.h | 1 +
> 4 files changed, 97 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_simple_shaders.c
> b/src/gallium/auxiliary/util/u_simple_shaders.c
> index adf4887..2cf528b 100644
> --- a/src/gallium/auxiliary/util/u_simple_shaders.c
> +++ b/src/gallium/auxiliary/util/u_simple_shaders.c
> @@ -124,6 +124,76 @@ void *util_make_layered_clear_vertex_shader(struct
> pipe_context *pipe)
> return pipe->create_vs_state(pipe, &state);
> }
>
> +/**
> + * Takes position and color, and outputs position, color, and instance id.
> + */
> +void *util_make_layered_clear_helper_vertex_shader(struct pipe_context *pipe)
> +{
> + static const char text[] =
> + "VERT\n"
> + "DCL IN[0]\n"
> + "DCL IN[1]\n"
> + "DCL SV[0], INSTANCEID\n"
> + "DCL OUT[0], POSITION\n"
> + "DCL OUT[1], GENERIC[0]\n"
> + "DCL OUT[2], GENERIC[1]\n"
> +
> + "MOV OUT[0], IN[0]\n"
> + "MOV OUT[1], IN[1]\n"
> + "MOV OUT[2].x, SV[0].\n"
> + "END\n";
> + struct tgsi_token tokens[1000];
> + struct pipe_shader_state state = {tokens};
> +
> + if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
> + assert(0);
> + return NULL;
> + }
> + return pipe->create_vs_state(pipe, &state);
> +}
> +
> +/**
> + * Takes position, color, and target layer, and emits vertices on that target
> + * layer, with the specified color.
> + */
> +void *util_make_layered_clear_geometry_shader(struct pipe_context *pipe)
> +{
> + static const char text[] =
> + "GEOM\n"
> + "PROPERTY GS_INPUT_PRIMITIVE TRIANGLES\n"
> + "PROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP\n"
> + "PROPERTY GS_MAX_OUTPUT_VERTICES 3\n"
> + "PROPERTY GS_INVOCATIONS 1\n"
> + "DCL IN[][0], POSITION\n" /* position */
> + "DCL IN[][1], GENERIC[0]\n" /* color */
> + "DCL IN[][2], GENERIC[1]\n" /* vs invocation */
> + "DCL OUT[0], POSITION\n"
> + "DCL OUT[1], GENERIC[0]\n"
> + "DCL OUT[2], LAYER\n"
> + "IMM[0] INT32 {0, 0, 0, 0}\n"
> +
> + "MOV OUT[0], IN[0][0]\n"
> + "MOV OUT[1], IN[0][1]\n"
> + "MOV OUT[2].x, IN[0][2].\n"
> + "EMIT IMM[0].\n"
> + "MOV OUT[0], IN[1][0]\n"
> + "MOV OUT[1], IN[1][1]\n"
> + "MOV OUT[2].x, IN[1][2].\n"
> + "EMIT IMM[0].\n"
> + "MOV OUT[0], IN[2][0]\n"
> + "MOV OUT[1], IN[2][1]\n"
> + "MOV OUT[2].x, IN[2][2].\n"
> + "EMIT IMM[0].\n"
> + "END\n";
> + struct tgsi_token tokens[1000];
> + struct pipe_shader_state state = {tokens};
> +
> + if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
> + assert(0);
> + return NULL;
> + }
> + return pipe->create_gs_state(pipe, &state);
> +}
>
> /**
> * Make simple fragment texture shader:
> diff --git a/src/gallium/auxiliary/util/u_simple_shaders.h
> b/src/gallium/auxiliary/util/u_simple_shaders.h
> index c1d14aa..b467b9f5 100644
> --- a/src/gallium/auxiliary/util/u_simple_shaders.h
> +++ b/src/gallium/auxiliary/util/u_simp
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 > > http://msdn.microsoft.com/en-gb/library/windows/desktop/bb509647.aspx > > 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] EXT/ARB direct state access extensions
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] The ARB_shader_subroutine extension
Hello once again, This time, I would like to ask about the shader subroutine extension. I believe this extension is not very popular, but is still needed for GL4 compliance. What is the reason for its unpopularity? Is it because one needs to reset subroutine uniform values after any glUse*? Or it just didn't provide enough value? Wouldn't it be good to implement uber-shaders (especially using subroutine uniform array)? Is anybody actively working on it? I guess, there are changes needed in the GLSL compiler. It could be easily lowered to a switch-on-uniform-int thing, or something like that, if only compliance to the GL4 matters and not the performance. Regards, Gustaw ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] tinderbox build regression
On 16/11/14 05:20, Dave Airlie wrote: > no idea but I'm picking Emil as the culprit! > Yes that was me. Apologies for the breakage Dave, it seems that rebasing that commit did cause some fun. Afaics Jose (big thanks) has fixed it already, but if there is anything else please let me know. -Emil ___ 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
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
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] The ARB_shader_subroutine extension
Hi Gustaw, My understanding is that it's a combination of the awkward API, and dubious value. It's certainly not something that everyone is screaming for. As far as mesa's implementation goes, I started on the parser changes and tests a while ago; I believe Ian was going to pick it up. I'm not sure whether he's had time to do much on it though. -- Chris On Mon, Nov 17, 2014 at 5:31 AM, Gustaw Smolarczyk wrote: > Hello once again, > > This time, I would like to ask about the shader subroutine extension. > I believe this extension is not very popular, but is still needed for > GL4 compliance. > > What is the reason for its unpopularity? > Is it because one needs to reset subroutine uniform values after any glUse*? > Or it just didn't provide enough value? > Wouldn't it be good to implement uber-shaders (especially using > subroutine uniform array)? > > Is anybody actively working on it? I guess, there are changes needed > in the GLSL compiler. It could be easily lowered to a > switch-on-uniform-int thing, or something like that, if only > compliance to the GL4 matters and not the performance. > > Regards, > Gustaw > ___ > 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] Request for more info in implementing atomic counters in mesa state tracker
Hi, I am currently working on implementing the extension *GL_ARB_shader_atomic_counters*. I have a few questions. 1. What does CSO and cso_context for? Why do we have to bind with it? 2. There is a file called st_atom_constbuf.c/.h in mesa/state_tracker. As counter buffers are different from constant buffers, is it ok to create a new file say, st_atom_countbuf.c/.h? 3. Counter buffers dont do "upload_data". But, they take offsets. Do I have to create a new cso api say cso_set_counter_buffer(**) to upload the data or can use the cso_st_constant_buffer interface with some of the variables set to NULL? 4. The st_context has struct state.constants this data type takes void pointer and size which are specific to constant buffers. Do we have to create something similar to that or can we ignore it (no pointer and size are needed for counters)? -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [10.4] git describe points to 10.2-branchpoint-3617-ga4ffc2a
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 - Sedat - ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] feature request for mesamatrix.net
Hi, I appreciate the work you've done to make the GL3.txt file much more readable. To improve it even more I would like to be able to click on the extensions names and see the whole text of the extension from the registry on opengl.org. I think it would help to understand why something isn't implemented yet and if it looks difficult, etc. Best Regards, David Odin -- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] fix typo which makes drmOpen("VALID_NAME", NULL) to return NULL
Signed-off-by: Guo Yejun
---
xf86drm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index d900b4b..40997d2 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -553,9 +553,8 @@ static int drmOpenByName(const char *name)
drmFreeVersion(version);
id = drmGetBusid(fd);
drmMsg("drmGetBusid returned '%s'\n", id ? id : "NULL");
- if (!id || !*id) {
- if (id)
- drmFreeBusid(id);
+ if (id) {
+ drmFreeBusid(id);
return fd;
} else {
drmFreeBusid(id);
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/16] glsl: Add ir_binop_pow to get_range
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))
+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;
}
--
2.0.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/16] glsl: Add sqrt, rsq, exp, exp2 to get_range
Also handle undefined behaviour for sqrt(x) where x < 0 and rsq(x) where x <= 0. This gives us some reduction in instruction count on some Dungeon Defenders shaders as they are doing: max(exp(x), 0) --- src/glsl/opt_minmax.cpp | 17 + 1 file changed, 17 insertions(+) diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp index a48d4d8..1aa4611 100644 --- a/src/glsl/opt_minmax.cpp +++ b/src/glsl/opt_minmax.cpp @@ -293,6 +293,23 @@ get_range(ir_rvalue *rval) high = larger_constant(r0.high, abs(r0.low)->constant_expression_value()); return minmax_range(low, high); + case ir_unop_sqrt: + case ir_unop_rsq: + case ir_unop_exp: + case ir_unop_exp2: + r0 = get_range(expr->operands[0]); + if (expr->operation == ir_unop_sqrt && + is_less_than_zero(r0.high)) +high = new(mem_ctx) ir_constant(0.0f); + if (expr->operation == ir_unop_rsq && + is_less_than_or_equal_zero(r0.high)) +high = new(mem_ctx) ir_constant(0.0f); + /* TODO: If we know, i.e, the lower range of the operand + * we can calculate the lower range + */ + low = new(mem_ctx) ir_constant(0.0f); + return minmax_range(low, NULL); + case ir_unop_sin: case ir_unop_sin_reduced: case ir_unop_cos: -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/16] glsl: Add sin, cos and sign to get_range
They are bound between -1 and 1, so report that.
---
src/glsl/opt_minmax.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 111d183..341006e 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -271,6 +271,10 @@ get_range(ir_rvalue *rval)
minmax_range r0;
minmax_range r1;
+ void *mem_ctx = ralloc_parent(rval);
+ ir_constant *low = NULL;
+ ir_constant *high = NULL;
+
if(expr) {
switch(expr->operation) {
case ir_binop_min:
@@ -279,6 +283,15 @@ get_range(ir_rvalue *rval)
r1 = get_range(expr->operands[1]);
return combine_range(r0, r1, expr->operation == ir_binop_min);
+ case ir_unop_sin:
+ case ir_unop_sin_reduced:
+ case ir_unop_cos:
+ case ir_unop_cos_reduced:
+ case ir_unop_sign:
+ high = new(mem_ctx) ir_constant(1.0f);
+ low = new(mem_ctx) ir_constant(-1.0f);
+ return minmax_range(low, high);
+
default:
break;
}
--
2.0.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/16] glsl: Add log and log2 to get_range
The spec states that log / log2 of x <= 0 is undefined.
Just set the range to 0 if this is the case.
---
src/glsl/opt_minmax.cpp | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index ad8c88a..0638a12 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -346,6 +346,20 @@ get_range(ir_rvalue *rval)
}
return minmax_range(low, high);
+ case ir_unop_log:
+ case ir_unop_log2:
+ r0 = get_range(expr->operands[0]);
+ if (is_greater_than_or_equal_one(r0.low))
+low = new(mem_ctx) ir_constant(0.0f);
+ if (is_less_than_or_equal_one(r0.high))
+high = new(mem_ctx) ir_constant(0.0f);
+ // Result is undefined, so we can set the range to whatever
+ if (is_less_than_or_equal_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;
}
--
2.0.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/16] glsl: Add ir_binop_mul to get_range
---
src/glsl/opt_minmax.cpp | 33 +
1 file changed, 33 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 9d300d3..49a816e 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -344,6 +344,39 @@ get_range(ir_rvalue *rval)
high = sub(r0.high, r1.low)->constant_expression_value();
return minmax_range(low, high);
+ case ir_binop_mul:
+ r0 = get_range(expr->operands[0]);
+ r1 = get_range(expr->operands[1]);
+ // Both are positive, result is positive
+ if (r0.low && is_greater_than_or_equal_zero(r0.low) &&
+r1.low && is_greater_than_or_equal_zero(r1.low)) {
+low = mul(r0.low, r1.low)->constant_expression_value();
+if (r0.high && r1.high)
+ high = mul(r0.high, r1.high)->constant_expression_value();
+ }
+ // Both are negative, result is positive
+ if (r0.high && is_less_than_or_equal_zero(r0.high) &&
+r1.high && is_less_than_or_equal_zero(r1.high)) {
+low = mul(r0.high, r1.high)->constant_expression_value();
+if (r0.low && r1.low)
+ high = mul(r0.low, r1.low)->constant_expression_value();
+ }
+ // r0 positive, r1 negative, result is negative
+ if (r0.low && is_greater_than_or_equal_zero(r0.low) &&
+r1.high && is_less_than_or_equal_zero(r1.high)) {
+high = mul(r0.low, r1.high)->constant_expression_value();
+if (r0.high && r1.low)
+ low = mul(r0.high, r1.low)->constant_expression_value();
+ }
+ // r0 negative, r1 positive, result is negative
+ if (r1.low && is_greater_than_or_equal_zero(r1.low) &&
+r0.high && is_less_than_or_equal_zero(r0.high)) {
+high = mul(r0.high, r1.low)->constant_expression_value();
+if (r0.low && r1.high)
+ low = mul(r0.low, 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))
--
2.0.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/16] glsl: Add ir_unop_neg to get_range
--- src/glsl/opt_minmax.cpp | 8 1 file changed, 8 insertions(+) diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp index 49a816e..466db8c 100644 --- a/src/glsl/opt_minmax.cpp +++ b/src/glsl/opt_minmax.cpp @@ -293,6 +293,14 @@ get_range(ir_rvalue *rval) high = larger_constant(r0.high, abs(r0.low)->constant_expression_value()); return minmax_range(low, high); + case ir_unop_neg: + r0 = get_range(expr->operands[0]); + if (r0.high) +low = neg(r0.high)->constant_expression_value(); + if (r0.low) +high = neg(r0.low)->constant_expression_value(); + return minmax_range(low, high); + case ir_unop_sqrt: case ir_unop_rsq: case ir_unop_exp: -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/16] glsl: Add ir_binop_add to get_range
--- src/glsl/opt_minmax.cpp | 9 + 1 file changed, 9 insertions(+) diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp index 1aa4611..9852dd9 100644 --- a/src/glsl/opt_minmax.cpp +++ b/src/glsl/opt_minmax.cpp @@ -326,6 +326,15 @@ get_range(ir_rvalue *rval) // We can get the intersection here to limit the range even more return range_intersection(r0, minmax_range(low, high)); + case ir_binop_add: + r0 = get_range(expr->operands[0]); + r1 = get_range(expr->operands[1]); + if(r0.low && r1.low) +low = add(r0.low, r1.low)->constant_expression_value(); + if(r0.high && r1.high) +high = add(r0.high, r1.high)->constant_expression_value(); + return minmax_range(low, high); + default: break; } -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/16] glsl: Change to using switch-case in get_range
This will make expansion easier and less cluttered.
---
src/glsl/opt_minmax.cpp | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 89970d5..111d183 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -268,11 +268,20 @@ static minmax_range
get_range(ir_rvalue *rval)
{
ir_expression *expr = rval->as_expression();
- if (expr && (expr->operation == ir_binop_min ||
-expr->operation == ir_binop_max)) {
- minmax_range r0 = get_range(expr->operands[0]);
- minmax_range r1 = get_range(expr->operands[1]);
- return combine_range(r0, r1, expr->operation == ir_binop_min);
+ minmax_range r0;
+ minmax_range r1;
+
+ if(expr) {
+ switch(expr->operation) {
+ case ir_binop_min:
+ case ir_binop_max:
+ r0 = get_range(expr->operands[0]);
+ r1 = get_range(expr->operands[1]);
+ return combine_range(r0, r1, expr->operation == ir_binop_min);
+
+ default:
+ break;
+ }
}
ir_constant *c = rval->as_constant();
--
2.0.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/16] glsl: Add saturate to get_range
We can use the intersection function to reduce the range even further if the operand has bounds between 0.0 and 1.0. --- src/glsl/opt_minmax.cpp | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp index 341006e..b925aaa 100644 --- a/src/glsl/opt_minmax.cpp +++ b/src/glsl/opt_minmax.cpp @@ -292,6 +292,13 @@ get_range(ir_rvalue *rval) low = new(mem_ctx) ir_constant(-1.0f); return minmax_range(low, high); + case ir_unop_saturate: + high = new(mem_ctx) ir_constant(1.0f); + low = new(mem_ctx) ir_constant(0.0f); + r0 = get_range(expr->operands[0]); + // We can get the intersection here to limit the range even more + return range_intersection(r0, minmax_range(low, high)); + default: break; } -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/16] glsl: Add ir_binop_sub to get_range
--- src/glsl/opt_minmax.cpp | 9 + 1 file changed, 9 insertions(+) diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp index 0638a12..9d300d3 100644 --- a/src/glsl/opt_minmax.cpp +++ b/src/glsl/opt_minmax.cpp @@ -335,6 +335,15 @@ get_range(ir_rvalue *rval) high = add(r0.high, r1.high)->constant_expression_value(); return minmax_range(low, high); + case ir_binop_sub: + r0 = get_range(expr->operands[0]); + r1 = get_range(expr->operands[1]); + if (r0.low && r1.high) +low = sub(r0.low, r1.high)->constant_expression_value(); + if(r0.high && r1.low) +high = sub(r0.high, r1.low)->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)) -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/16] glsl: Add ir_unop_rcp to get_range
---
src/glsl/opt_minmax.cpp | 24
1 file changed, 24 insertions(+)
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 466db8c..96b1e07 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -301,6 +301,30 @@ get_range(ir_rvalue *rval)
high = neg(r0.low)->constant_expression_value();
return minmax_range(low, high);
+ case ir_unop_rcp:
+ r0 = get_range(expr->operands[0]);
+ if (is_greater_than_zero(r0.low)) {
+ir_expression *h = new(mem_ctx) ir_expression(ir_unop_rcp, r0.low);
+high = h->constant_expression_value();
+if (r0.high) {
+ ir_expression *l = new(mem_ctx) ir_expression(ir_unop_rcp,
r0.high);
+ low = l->constant_expression_value();
+}
+ }
+ if (is_less_than_zero(r0.low) && is_less_than_zero(r0.high)) {
+ir_expression *h = new(mem_ctx) ir_expression(ir_unop_rcp, r0.low);
+high = h->constant_expression_value();
+ir_expression *l = new(mem_ctx) ir_expression(ir_unop_rcp,
r0.high);
+low = l->constant_expression_value();
+ }
+ if (is_less_than_zero(r0.low) && is_greater_than_zero(r0.high)) {
+ir_expression *h = new(mem_ctx) ir_expression(ir_unop_rcp,
r0.high);
+high = h->constant_expression_value();
+ir_expression *l = new(mem_ctx) ir_expression(ir_unop_rcp, r0.low);
+low = l->constant_expression_value();
+ }
+ return minmax_range(low, high);
+
case ir_unop_sqrt:
case ir_unop_rsq:
case ir_unop_exp:
--
2.0.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/16] glsl: Reorder optimization-passes
This allows opt_algebraic to resolve open-coded saturates into ir_unop_saturate before we potentially mess it up by removing the min or max in min/max-pruning. Since we are now emitting more free saturates on i965 this gives us some decrease in instructions. total instructions in shared programs: 1317459 -> 1317065 (-0.03%) instructions in affected programs: 4084 -> 3690 (-9.65%) GAINED:0 LOST: 0 --- Two purpose-written shaders are hurt by this. They exercise the lack of saturate in the get_range function in minmax_pruning. This will get sorted out later in the series by adding saturate to the get_range function. --- src/glsl/glsl_parser_extras.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp index 27e3301..5c98df5 100644 --- a/src/glsl/glsl_parser_extras.cpp +++ b/src/glsl/glsl_parser_extras.cpp @@ -1619,10 +1619,10 @@ do_common_optimization(exec_list *ir, bool linked, else progress = do_constant_variable_unlinked(ir) || progress; progress = do_constant_folding(ir) || progress; + progress = do_algebraic(ir, native_integers, options) || progress; progress = do_minmax_prune(ir) || progress; progress = do_cse(ir) || progress; progress = do_rebalance_tree(ir) || progress; - progress = do_algebraic(ir, native_integers, options) || progress; progress = do_lower_jumps(ir) || progress; progress = do_vec_index_to_swizzle(ir) || progress; progress = lower_vector_insert(ir, false) || progress; -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/16] glsl: Move common code to ir_constant_util.h
This will allow for less code duplication.
I'll be using this in opt_minmax in the coming commits.
---
src/glsl/ir_constant_util.h | 122
src/glsl/opt_algebraic.cpp | 88 +---
src/glsl/opt_minmax.cpp | 17 +-
3 files changed, 124 insertions(+), 103 deletions(-)
create mode 100644 src/glsl/ir_constant_util.h
diff --git a/src/glsl/ir_constant_util.h b/src/glsl/ir_constant_util.h
new file mode 100644
index 000..4e0fede
--- /dev/null
+++ b/src/glsl/ir_constant_util.h
@@ -0,0 +1,122 @@
+/*
+ * Copyright © 2010 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+/**
+ * \file ir_constant_util.h
+ *
+ * A collection of utility functions for use on constants
+ * Shamelessly cut-pasted from opt_algebraic, etc
+ *
+ * Author: Thomas Helland
+ */
+
+#ifndef IR_CONSTANT_UTIL_H_
+#define IR_CONSTANT_UTIL_H_
+
+#include "main/macros.h"
+#include "ir_builder.h"
+#include "program/prog_instruction.h"
+
+using namespace ir_builder;
+
+/* When eliminating an expression and just returning one of its operands,
+ * we may need to swizzle that operand out to a vector if the expression was
+ * vector type.
+ */
+static ir_rvalue *
+swizzle_if_required(ir_expression *expr,
+ ir_rvalue *operand)
+{
+ if (expr->type->is_vector() && operand->type->is_scalar()) {
+ return swizzle(operand, SWIZZLE_, expr->type->vector_elements);
+ } else
+ return operand;
+}
+
+static inline bool
+is_vec_zero(ir_constant *ir)
+{
+ return (ir == NULL) ? false : ir->is_zero();
+}
+
+static inline bool
+is_vec_one(ir_constant *ir)
+{
+ return (ir == NULL) ? false : ir->is_one();
+}
+
+static inline bool
+is_vec_two(ir_constant *ir)
+{
+ return (ir == NULL) ? false : ir->is_value(2.0, 2);
+}
+
+static inline bool
+is_vec_negative_one(ir_constant *ir)
+{
+ return (ir == NULL) ? false : ir->is_negative_one();
+}
+
+static inline bool
+is_valid_vec_const(ir_constant *ir)
+{
+ if (ir == NULL)
+ return false;
+
+ if (!ir->type->is_scalar() && !ir->type->is_vector())
+ return false;
+
+ return true;
+}
+
+static inline bool
+is_less_than_one(ir_constant *ir)
+{
+ if (!is_valid_vec_const(ir))
+ return false;
+
+ unsigned component = 0;
+ for (int c = 0; c < ir->type->vector_elements; c++) {
+ if (ir->get_float_component(c) < 1.0f)
+ component++;
+ }
+
+ return (component == ir->type->vector_elements);
+}
+
+static inline bool
+is_greater_than_zero(ir_constant *ir)
+{
+ if (!is_valid_vec_const(ir))
+ return false;
+
+ unsigned component = 0;
+ for (int c = 0; c < ir->type->vector_elements; c++) {
+ if (ir->get_float_component(c) > 0.0f)
+ component++;
+ }
+
+ return (component == ir->type->vector_elements);
+}
+
+#endif /* IR_CONSTANT_UTIL_H_ */
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index af1f544..8c2f15c 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -29,13 +29,10 @@
*/
#include "ir.h"
-#include "ir_visitor.h"
#include "ir_rvalue_visitor.h"
#include "ir_optimization.h"
-#include "ir_builder.h"
#include "glsl_types.h"
-
-using namespace ir_builder;
+#include "ir_constant_util.h"
namespace {
@@ -68,8 +65,6 @@ public:
int op1,
ir_expression *ir2,
int op2);
- ir_rvalue *swizzle_if_required(ir_expression *expr,
- ir_rvalue *operand);
const struct gl_shader_compiler_options *options;
void *mem_ctx;
@@ -80,72 +75,6 @@ public:
} /* unnamed namespace */
-static inline bool
-is_vec_zero(ir_constant *ir)
-{
- return (ir == NULL) ? false : ir->is_zero();
-}
-
-static inline bool
-is_vec_one(ir_constant *ir)
-{
- return (ir == NULL) ? false : ir->is_one();
-}
-
-static inline bool
-
[Mesa-dev] [PATCH 08/16] glsl: Add abs to get_range
--- src/glsl/opt_minmax.cpp | 10 ++ 1 file changed, 10 insertions(+) diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp index b925aaa..a48d4d8 100644 --- a/src/glsl/opt_minmax.cpp +++ b/src/glsl/opt_minmax.cpp @@ -283,6 +283,16 @@ get_range(ir_rvalue *rval) r1 = get_range(expr->operands[1]); return combine_range(r0, r1, expr->operation == ir_binop_min); + case ir_unop_abs: + r0 = get_range(expr->operands[0]); + if (is_greater_than_zero(r0.low)) +low = r0.low; + else +low = new(mem_ctx) ir_constant(0.0f); + if (r0.high && r0.low) +high = larger_constant(r0.high, abs(r0.low)->constant_expression_value()); + return minmax_range(low, high); + case ir_unop_sin: case ir_unop_sin_reduced: case ir_unop_cos: -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/16] glsl: Add EmitNoSaturate to shader compiler options
This allows the backend to decide if it does not want saturates, or if it wants to combine min/max together by itself. Usefull for drivers that implement saturate with min/max as it can allow for some optimizations by min/max-pruning. Drivers like freedreno and vc4 will benefit. --- I have not made any drivers set the option. Probably some pipe-cap or something is needed in gallium to allow this? I could possibly find time to do a follow-up patch for this if someone leads me in the right direction. saturate() in ir_builder generates ir_unop_saturate unconditionally. If someone comes along later and does saturate() in some optimization pass, whithout checking the options, they will mess up possible optimizations for some backends. The cleanest way I could find for always doing the right thing was to write a lowering pass in opt_algebraic to lower ir_unop_sature into max(min(x, 1), 0); The other alternative would be to rewrite the saturate() to use max(min(x, 1), 0) like it used to, and rewrite the part in opt_algebraic that detects hand-rolled saturate to instead do: new expression(ir_unop_saturate, x); --- src/glsl/opt_algebraic.cpp | 12 src/mesa/main/mtypes.h | 1 + 2 files changed, 13 insertions(+) diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp index 430f5cb..af1f544 100644 --- a/src/glsl/opt_algebraic.cpp +++ b/src/glsl/opt_algebraic.cpp @@ -682,6 +682,10 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir) if (ir->type->base_type != GLSL_TYPE_FLOAT) break; + // Only emit saturate if the option is set + if (options->EmitNoSaturate) + break; + /* Replace min(max) operations and its commutative combinations with * a saturate operation */ @@ -787,6 +791,14 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir) return ir->operands[2]; break; + case ir_unop_saturate: + if (options->EmitNoSaturate) + return expr(ir_binop_max, + expr(ir_binop_min, ir->operands[0], + new(mem_ctx) ir_constant(1.0f)), + new(mem_ctx) ir_constant(0.0f)); + break; + default: break; } diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 7389baa..922e88b 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -2990,6 +2990,7 @@ struct gl_shader_compiler_options GLboolean EmitNoMainReturn;/**< Emit CONT/RET opcodes? */ GLboolean EmitNoNoise; /**< Emit NOISE opcodes? */ GLboolean EmitNoPow; /**< Emit POW opcodes? */ + GLboolean EmitNoSaturate; /**< Emit SATURATE opcodes? */ GLboolean LowerClipDistance; /**< Lower gl_ClipDistance from float[8] to vec4[2]? */ /** -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/16] Expand opt_minmax get_range v2
My exams are aproaching fast, so I thought I'd put this second version of the series onto the list. This hopefully addresses the issues with the first version. I have tested that I don't cause regressions with Brutal Legend, and that I maintain the improvement in Dungeon Defenders. These are the only ones of the games Matt mentioned changes in that I've got in my arsenal, so I can not vouch for the rest. Oh, and of course a full piglit run with no changes reported. There's a nice improvement to Dota2 due to patch 2 which, as suggested by Ian, also fixes the Brutal Legend regression :) I've resolved undefined behaviour in operations like pow, log, sqrt, etc to emit bounds corresponding to a constant zero. I'm also working on a pass to replace undefined behaviour in these operations with a constant zero. Some of the additions I've made to get-range operate vector-wise. It would probably be benefitial to operate component-wise. It should allow more constants to be folded/prop. up the tree which would be a benefit at least for scalar backends? I'm still putting together a tactic on how to do this so if there's any good suggestions then please speak out. For copyright header on the ir_constant_util.h file I basically copy-pasted the license header from opt_algebraic. The rationale was that the code itself was a copy-pasta from here with no real additions from my side. Is this an acceptable approach? CC: Matt Turner CC: Ian Romanick Thomas Helland (16): glsl: Add EmitNoSaturate to shader compiler options glsl: Reorder optimization-passes glsl: Move common code to ir_constant_util.h glsl: Expand constant_util glsl: Change to using switch-case in get_range glsl: Add sin, cos and sign to get_range glsl: Add saturate to get_range glsl: Add abs to get_range glsl: Add sqrt, rsq, exp, exp2 to get_range glsl: Add ir_binop_add to get_range glsl: Add ir_binop_pow to get_range glsl: Add log and log2 to get_range glsl: Add ir_binop_sub to get_range glsl: Add ir_binop_mul to get_range glsl: Add ir_unop_neg to get_range glsl: Add ir_unop_rcp to get_range src/glsl/glsl_parser_extras.cpp | 2 +- src/glsl/ir_constant_util.h | 172 src/glsl/opt_algebraic.cpp | 100 +++-- src/glsl/opt_minmax.cpp | 191 +++- src/mesa/main/mtypes.h | 1 + 5 files changed, 357 insertions(+), 109 deletions(-) create mode 100644 src/glsl/ir_constant_util.h -- 2.0.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/16] glsl: Expand constant_util
Add functions:
is_greater_than_one
is_less_than_zero
Add variations like greater_than_or_equal_zero.
---
This is not ideal computation-wise, as we are doing two
iterations instead of one. The question is wether or not
the extra code is worth the duplicaton.
---
src/glsl/ir_constant_util.h | 50 +
1 file changed, 50 insertions(+)
diff --git a/src/glsl/ir_constant_util.h b/src/glsl/ir_constant_util.h
index 4e0fede..dd6452b 100644
--- a/src/glsl/ir_constant_util.h
+++ b/src/glsl/ir_constant_util.h
@@ -105,6 +105,21 @@ is_less_than_one(ir_constant *ir)
}
static inline bool
+is_greater_than_one(ir_constant *ir)
+{
+ if (!is_valid_vec_const(ir))
+ return false;
+
+ unsigned component = 0;
+ for (int c = 0; c < ir->type->vector_elements; c++) {
+ if (ir->get_float_component(c) > 1.0f)
+ component++;
+ }
+
+ return (component == ir->type->vector_elements);
+}
+
+static inline bool
is_greater_than_zero(ir_constant *ir)
{
if (!is_valid_vec_const(ir))
@@ -119,4 +134,39 @@ is_greater_than_zero(ir_constant *ir)
return (component == ir->type->vector_elements);
}
+static inline bool
+is_less_than_zero(ir_constant *ir)
+{
+ if (!is_valid_vec_const(ir))
+ return false;
+
+ unsigned component = 0;
+ for (int c = 0; c < ir->type->vector_elements; c++) {
+ if (ir->get_float_component(c) < 0.0f)
+ component++;
+ }
+
+ return (component == ir->type->vector_elements);
+}
+
+static inline bool
+is_less_than_or_equal_zero(ir_constant *ir) {
+ return is_less_than_zero(ir) || is_vec_zero(ir);
+}
+
+static inline bool
+is_greater_than_or_equal_zero(ir_constant *ir) {
+ return is_greater_than_zero(ir) || is_vec_zero(ir);
+}
+
+static inline bool
+is_less_than_or_equal_one(ir_constant *ir) {
+ return is_less_than_one(ir) || is_vec_one(ir);
+}
+
+static inline bool
+is_greater_than_or_equal_one(ir_constant *ir) {
+ return is_greater_than_one(ir) || is_vec_one(ir);
+}
+
#endif /* IR_CONSTANT_UTIL_H_ */
--
2.0.3
___
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
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.
See https://github.com/imirkin/mesa/commits/atomic
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 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_constant_buffer {
> const void *user_buffer; /**< pointer to a user buffer if buffer == NULL
> */
> };
>
> +/**
> + * A Counter buffer. A new buffer is set everytime a variable with
> + * atomic_uint is defined.
> + */
> +struct pipe_counter_buffer{
> + struct pipe_resource *buffer; /**< The actual buffer */
> + unsigned buffer_offset; /**< The offset to start of data in buffer in
> bytes */
> + const void *user_buffer; /**< The buffer which is created by the compiler
> */
> +};
>
> /**
> * A stream output target. The structure specifies the range vertices can
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/16] glsl: Add EmitNoSaturate to shader compiler options
On Sun, Nov 16, 2014 at 5:51 PM, Thomas Helland wrote: > This allows the backend to decide if it does not > want saturates, or if it wants to combine min/max > together by itself. > > Usefull for drivers that implement saturate with min/max > as it can allow for some optimizations by min/max-pruning. > Drivers like freedreno and vc4 will benefit. > --- > I have not made any drivers set the option. > Probably some pipe-cap or something is needed > in gallium to allow this? > I could possibly find time to do a follow-up > patch for this if someone leads me in the right direction. > > saturate() in ir_builder generates ir_unop_saturate unconditionally. > If someone comes along later and does saturate() > in some optimization pass, whithout checking the options, > they will mess up possible optimizations for some backends. > The cleanest way I could find for always doing the right > thing was to write a lowering pass in opt_algebraic to > lower ir_unop_sature into max(min(x, 1), 0); We already have that, so no need for work in that area :) See lower_instructions_visitor::sat_to_clamp(). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/16] glsl: Add EmitNoSaturate to shader compiler options
On Sun, Nov 16, 2014 at 7:33 PM, Matt Turner wrote: > On Sun, Nov 16, 2014 at 5:51 PM, Thomas Helland > wrote: >> This allows the backend to decide if it does not >> want saturates, or if it wants to combine min/max >> together by itself. >> >> Usefull for drivers that implement saturate with min/max >> as it can allow for some optimizations by min/max-pruning. >> Drivers like freedreno and vc4 will benefit. >> --- >> I have not made any drivers set the option. >> Probably some pipe-cap or something is needed >> in gallium to allow this? >> I could possibly find time to do a follow-up >> patch for this if someone leads me in the right direction. >> >> saturate() in ir_builder generates ir_unop_saturate unconditionally. >> If someone comes along later and does saturate() >> in some optimization pass, whithout checking the options, >> they will mess up possible optimizations for some backends. >> The cleanest way I could find for always doing the right >> thing was to write a lowering pass in opt_algebraic to >> lower ir_unop_sature into max(min(x, 1), 0); > > We already have that, so no need for work in that area :) > > See lower_instructions_visitor::sat_to_clamp(). ... and as a result the second hunk of this patch isn't needed. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/16] glsl: Expand constant_util
On Sun, Nov 16, 2014 at 5:51 PM, Thomas Helland wrote: > Add functions: > is_greater_than_one > is_less_than_zero > > Add variations like greater_than_or_equal_zero. > --- > This is not ideal computation-wise, as we are doing two > iterations instead of one. The question is wether or not > the extra code is worth the duplicaton. Now that all of these functions are in a header, maybe the best thing to do is to actually use macros? Something like IS_CONSTANT(ir, operator, operand) so we can do IS_CONSTANT(ir, >=, 0.0f) or something like that. What do other compiler people think? ___ 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,
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_constant_buffer {
> > const void *user_buffer; /**< pointer to a user buffer if buffer ==
> NULL */
> > };
> >
> > +/**
> > + * A Counter buffer. A new buffer is set everytime a variable with
> > + * atomic_uint is defined.
> > + */
> > +struct pipe_counter_buffer{
> > + struct pipe_resourc
Re: [Mesa-dev] [PATCH 1/4] r600g/compute: Don't leak cbufs in compute state
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
