On May 21, 2015 9:41 AM, "Connor Abbott" wrote:
>
> The point of cleanup_defs_uses() is to make an instruction safe to
> remove by removing any references that the rest of the shader may have
> to it. Previously, it was handling register use/def sets and removing
> the instruction from the use set
On Thu, May 21, 2015 at 5:07 PM, Connor Abbott wrote:
> Some loops may have phi nodes that look like:
>
> foo = ...
> loop {
> bar = phi(foo, bar)
> ...
> }
>
> in which case we can remove the phi node and replace all uses of 'bar'
> with 'foo'. In particular, there are some L4D2 vertex sh
Reviewed-by: Jason Ekstrand
On May 21, 2015 9:41 AM, "Connor Abbott" wrote:
> We were rewriting the uses of the intrinsic instruction to point to
> something else after removing it, which only happened to work since we
> were lax about having dangling uses when removing instructions. Fix that
>
This looks totally sane to me.
Reviewed-by: Jason Ekstrand
I'll try and get some shader-db numbers for you tomorrow.
--Jason
On May 21, 2015 5:07 PM, "Connor Abbott" wrote:
>
> Some loops may have phi nodes that look like:
>
> foo = ...
> loop {
> bar = phi(foo, bar)
> ...
> }
>
> in w
On Thu, May 21, 2015 at 8:51 PM, Rogovin, Kevin wrote:
>
>> FWIW, the kernel standards for commit messages are at:
>> https://www.kernel.org/doc/Documentation/SubmittingPatches
>> Most of those rules apply to Mesa too. It says the body should be wrapped to
>> 75 chars (although I've been using 72
On Thu, May 21, 2015 at 8:40 PM, Rogovin, Kevin wrote:
>
>
>> I suppose it could be useful, but I think we've been mostly successful at
>> just expecting people to recognize when what they're writing doesn't look
>> like the code around it.
>
> This is my point. Older code had different style/ex
Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
_glapi_set_nop_handler() functions in the glapi dispatcher (which
live in libGL.so). The calls to those functions from context.c
would be undefined (i.e. an ABI break) if the libGL used at runtime
was older.
For the time being, use th
On 05/15/2015 02:28 PM, Emil Velikov wrote:
On 15/05/15 17:58, Brian Paul wrote:
On 05/15/2015 11:14 AM, Emil Velikov wrote:
On 15/05/15 15:13, Brian Paul wrote:
Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
_glapi_set_nop_handler() functions in the glapi dispatcher (which
liv
> FWIW, the kernel standards for commit messages are at:
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> Most of those rules apply to Mesa too. It says the body should be wrapped to
> 75 chars (although I've been using 72 like Matt said).
This is my point: "use most rules, but no
On Thu, May 21, 2015 at 5:26 PM, Rogovin, Kevin wrote:
> HI,
>
>
>
>>Or 78 columns, to be safe, but there's exceptions, like if you're
>> defining a big static table/array of info.
>
> Uggg I don't mind exceptions, but knowing them is key.
>
>
>
>>> 4. successive parenthesis must have spaces
On Thu, May 21, 2015 at 1:51 PM, Matt Turner wrote:
> On Thu, May 21, 2015 at 12:26 PM, Ben Widawsky wrote:
>> A lot of opinion stuff is below, feel free to ignore them if you don't think
>> there are improvements.
>>
>> On Fri, Apr 17, 2015 at 04:51:38PM -0700, Anuj Phogat wrote:
>>> This patch
On Thu, May 21, 2015 at 12:26 PM, Ben Widawsky wrote:
> A lot of opinion stuff is below, feel free to ignore them if you don't think
> there are improvements.
>
> On Fri, Apr 17, 2015 at 04:51:38PM -0700, Anuj Phogat wrote:
>> This patch enables using XY_FAST_COPY_BLT only for Yf/Ys tiled buffers.
On Thu, May 21, 2015 at 8:05 PM, Rogovin, Kevin wrote:
>
>> This line is too long. (It will not fit in 80 columns in git log since git
>> log adds some spaces before each commit message line.)
>
> What is the accepted maximum length for a line in a commit message?
>
>>> - extension table
>>> -
> I suppose it could be useful, but I think we've been mostly successful at
> just expecting people to recognize when what they're writing doesn't look
> like the code around it.
This is my point. Older code had different style/expectations than newer code.
For this patch series, I have hit a
On 05/21/2015 05:26 PM, Rogovin, Kevin wrote:
HI,
Or 78 columns, to be safe, but there's exceptions, like if you're
defining a big static table/array of info.
Uggg I don't mind exceptions, but knowing them is key.
4. successive parenthesis must have spaces between parenthesis
HI,
>Or 78 columns, to be safe, but there's exceptions, like if you're
> defining a big static table/array of info.
Uggg I don't mind exceptions, but knowing them is key.
>> 4. successive parenthesis must have spaces between parenthesis
> Example?
if (some_func(some_argument))
is
On Thu, May 21, 2015 at 5:05 PM, Rogovin, Kevin wrote:
>
>> This line is too long. (It will not fit in 80 columns in git log since git
>> log adds some spaces before each commit message line.)
>
> What is the accepted maximum length for a line in a commit message?
Gentoo's default vim configurat
On 05/21/2015 05:05 PM, Rogovin, Kevin wrote:
This line is too long. (It will not fit in 80 columns in git log since git log
adds some spaces before each commit message line.)
What is the accepted maximum length for a line in a commit message?
Probably 75 chars since there's 4 spaces of in
> Strange because of the types -- presumably fb_samples is an int because its
> uses are in a comparison with another int (that probably doesn't need to be
> an int :)
I am really hesitant to start changing types all over the place; I have a
sinking suspicion that changing the types of fb_width
Some loops may have phi nodes that look like:
foo = ...
loop {
bar = phi(foo, bar)
...
}
in which case we can remove the phi node and replace all uses of 'bar'
with 'foo'. In particular, there are some L4D2 vertex shaders with loops
that, after optimization, look like:
/* succs:
> This line is too long. (It will not fit in 80 columns in git log since git
> log adds some spaces before each commit message line.)
What is the accepted maximum length for a line in a commit message?
>> - extension table
>> - additions to gl_framebuffer
>>
>> v1 -> v2
>> Spacing and trail
On Fri, Apr 17, 2015 at 04:51:43PM -0700, Anuj Phogat wrote:
> This fixed the buffer corruption happening in a FBO which use YF/YS
> tiled renderbuffer or texture as color attachment.
>
> Spec recommends disabling mip tails for non-mip-mapped surfaces.
> But, with this enabled I couldn't get corre
On Thu, May 21, 2015 at 4:44 PM, Rogovin, Kevin wrote:
>> struct brw_state_flags state = brw->state.pipelines[pipeline];
>> + int fb_samples = (int)_mesa_geometric_samples(ctx->DrawBuffer);
>
>> The cast looks strange
>
> Is there a spacing missing in the cast? or is it strange because of th
Some commit message nits... :)
On 2015-05-21 14:30:48, wrote:
> From: Kevin Rogovin
>
> Define the infrastructure for the extension GL_ARB_framebuffer_no_attachments:
This line is too long. (It will not fit in 80 columns in git log since
git log adds some spaces before each commit message line
>> src/mesa/drivers/dri/i965/brw_misc_state.c | 10 +++---
> > src/mesa/drivers/dri/i965/brw_sf_state.c | 8
> As is this?
brw_misc_state.c is active for all Gens. The change to brw_sf_state.c is to
add a comment warning that using gl_framebuffer::Width and so o
On Thu, May 21, 2015 at 4:23 PM, Matt Turner wrote:
> On Thu, May 21, 2015 at 2:30 PM, wrote:
>> From: Kevin Rogovin
>>
>> This patch series implements:
>> - the needed functionality in Mesa-core for ARB_framebuffer_no_attachments
>> - implements and enables the extension i965
>
> I think t
> Extra space between . and "
Fix I will
> Extra space before .
Fix I will
> Also, if anyone is ever grepping for MAX_FRAMEBUFFER_SAMPLES, they won't find
> this. I'd move the whole word to the next line.
Ok.
> + *
> + * The same requirements are also in place for GL 4.5,
> +
On Fri, Apr 17, 2015 at 04:51:42PM -0700, Anuj Phogat wrote:
> Note: Yf/Ys tiling stays disabled to avoid any piglit regressions. I'm
> working on fixing the remaining piglit failures.
>
> We need to do some benchmarking to come up with conditions to choose
> Ys (64 KB) over Yf (4 KB). Any thought
On Thu, May 21, 2015 at 2:30 PM, wrote:
> From: Kevin Rogovin
>
> This patch series implements:
> - the needed functionality in Mesa-core for ARB_framebuffer_no_attachments
> - implements and enables the extension i965
I think there was one patch I didn't notice some kind of obvious style
p
On Thu, May 21, 2015 at 2:30 PM, wrote:
> From: Kevin Rogovin
>
> Implement GL_ARB_framebuffer_no_attachments in Mesa core
> - changes to conditions for framebuffer completenss
> - implement set/get functions for framebuffers for
>new functions in GL_ARB_framebuffer_no_attachments
>
> v1 -
On Thu, May 21, 2015 at 2:30 PM, wrote:
> From: Kevin Rogovin
>
> Add convenience helper functions for fetching geometry of gl_framebuffer
> that return the geometry of the gl_framebuffer instead of the geometry of
> the buffers of the gl_framebuffer when then the gl_framebuffer has no
> attachm
On Thu, May 21, 2015 at 2:30 PM, wrote:
> From: Kevin Rogovin
>
> Ensure that the GPU spawns the fragment shader thread for those
> fragment shaders with atomic buffer access.
>
> v1 -> v2
> No change.
>
> v2 -> v3
> Use utility function _mesa_active_fragment_shader_has_atomic_ops().
>
> Revie
On Thu, May 21, 2015 at 2:30 PM, wrote:
> From: Kevin Rogovin
>
> Add helper function that checks if current fragment shader active
> of gl_context has atomic buffer access.
>
> v1 -> v3
> Added in v3 of patch series.
>
> Signed-off-by: Kevin Rogovin
> ---
> src/mesa/main/mtypes.h | 7 ++-
On Thu, May 21, 2015 at 2:30 PM, wrote:
> From: Kevin Rogovin
>
> Change references to gl_framebuffer::Width, Height, MaxNumLayers
> and Visual::samples to use the _mesa_geometry_ convenience functions
> for those places where the geometry of the gl_framebuffer is needed
> (in contrast to the ge
On Fri, 2015-05-22 at 00:30 +0300, kevin.rogo...@intel.com wrote:
> From: Kevin Rogovin
>
> Mark GL_ARB_framebuffer_no_attachments as done for i965.
>
> v1 -> v2
> File added to patch series
>
> v2 -> v3
> docs/GL3.txt : add done mark under GLES3.1
> docs/relnotes/10.6.0.html : maintain alph
> I'm happy to see new documentation, so thanks for writing it up!
> But let's separate this from the functional changes related to implementing
> the extension. (Didn't I give this comment last time?)
If you did, I missed it. Unless there are objections, I'll remove this from the
series and m
Again, space after "mesa:" in the subject.
On Thu, May 21, 2015 at 2:30 PM, wrote:
> From: Kevin Rogovin
>
> Define the enumeration constants, function entry points and
> glGet for the GL_ARB_framebuffer_no_attachments.
>
> v1 -> v2
> Add output="true" for GetFramebufferParameteriv parameter p
> Subject: mesa:Define extension ARB_framebuffer_no_attachments
Space after "mesa:"
On Thu, May 21, 2015 at 2:30 PM, wrote:
> From: Kevin Rogovin
>
> Define the infrastructure for the extension GL_ARB_framebuffer_no_attachments:
> - extension table
> - additions to gl_framebuffer
>
> v1 -> v
On Thu, May 21, 2015 at 5:30 PM, wrote:
> From: Kevin Rogovin
>
> Mark GL_ARB_framebuffer_no_attachments as done for i965.
>
> v1 -> v2
> File added to patch series
>
> v2 -> v3
> docs/GL3.txt : add done mark under GLES3.1
> docs/relnotes/10.6.0.html : maintain alphabetical order
>
> Reviewed
Series is: Reviewed-by: Ilia Mirkin
But please adjust the commit descriptions to explain what they fix.
Like this fixes PIPELINE_STATISTICS with HUD. The previous one fixes
64-bit queries with HUD.
On Thu, May 21, 2015 at 5:58 PM, Samuel Pitoiset
wrote:
> Tested on NVA8. No regression for ARB_p
Tested on NVA8. No regression for ARB_pipeline_statistics piglit tests.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nv50/nv50_query.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c
b/src/gallium/drivers/nouv
A sequence number is written for 32-bits queries to make sure they are
ready, but not for 64-bits queries. Instead, we have to use a fence.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nv50/nv50_query.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff
On Thu, May 21, 2015 at 5:30 PM, wrote:
> From: Kevin Rogovin
If you set your email name to that, you won't get this funny mail, and
your name will appear properly in the actual email sent.
This is what I have in my .gitconfig:
[user]
email = imir...@alum.mit.edu
name = Ilia M
From: Kevin Rogovin
Mark GL_ARB_framebuffer_no_attachments as done for i965.
v1 -> v2
File added to patch series
v2 -> v3
docs/GL3.txt : add done mark under GLES3.1
docs/relnotes/10.6.0.html : maintain alphabetical order
Reviewed-by: Ian Romanick (v2)
Signed-off-by: Kevin Rogovin
---
do
From: Kevin Rogovin
Add convenience helper functions for fetching geometry of gl_framebuffer
that return the geometry of the gl_framebuffer instead of the geometry of
the buffers of the gl_framebuffer when then the gl_framebuffer has no
attachments.
v1 -> v2
Split from patch "mesa:helper-conve
From: Kevin Rogovin
Enable GL_ARB_framebuffer_no_attachments in i965 for Gen7 and higher.
v1 -> v2
No changes.
v2 -> v3
intel_extensions.c: Alphabetize insertion.
Reviewed-by: Ian Romanick (v2)
Signed-off-by: Kevin Rogovin
---
src/mesa/drivers/dri/i965/brw_context.c | 6 ++
src/m
From: Kevin Rogovin
Add helper convenience function that intersects the scissor values
against a passed bounding box. In addition, to avoid replicated code,
make the function _mesa_scissor_bounding_box() use this new function.
v1 -> v2
Split from patch "mesa:helper-conveniance functions for dri
From: Kevin Rogovin
Ensure that the GPU spawns the fragment shader thread for those
fragment shaders with atomic buffer access.
v1 -> v2
No change.
v2 -> v3
Use utility function _mesa_active_fragment_shader_has_atomic_ops().
Reviewed-by: Tapani Pälli (v1)
Signed-off-by: Kevin Rogovin
---
From: Kevin Rogovin
Add helper function that checks if current fragment shader active
of gl_context has atomic buffer access.
v1 -> v3
Added in v3 of patch series.
Signed-off-by: Kevin Rogovin
---
src/mesa/main/mtypes.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
From: Kevin Rogovin
Define the infrastructure for the extension GL_ARB_framebuffer_no_attachments:
- extension table
- additions to gl_framebuffer
v1 -> v2
Spacing and trailing spaces fixes.
v2 -> v3
mtypes.h: Correct comment on _HasAttachments.
Signed-off-by: Kevin Rogovin
---
src/mesa/
From: Kevin Rogovin
Change references to gl_framebuffer::Width, Height, MaxNumLayers
and Visual::samples to use the _mesa_geometry_ convenience functions
for those places where the geometry of the gl_framebuffer is needed
(in contrast to the geometry of the intersection of the attachments
of the
From: Kevin Rogovin
Implement GL_ARB_framebuffer_no_attachments in Mesa core
- changes to conditions for framebuffer completenss
- implement set/get functions for framebuffers for
new functions in GL_ARB_framebuffer_no_attachments
v1 -> v2
Spacing and exceed 80 characters per line fixes.
From: Kevin Rogovin
Define the enumeration constants, function entry points and
glGet for the GL_ARB_framebuffer_no_attachments.
v1 -> v2
Add output="true" for GetFramebufferParameteriv parameter params.
Alphabetical insertion.
v2 -> v3
Implement _mesa_GetFramebufferParameteriv and _mesa_F
From: Kevin Rogovin
This patch series implements:
- the needed functionality in Mesa-core for ARB_framebuffer_no_attachments
- implements and enables the extension i965
Kevin Rogovin (10):
mesa:Define extension ARB_framebuffer_no_attachments to gl_framebuffer
for extension ARB_framebuf
On Tuesday 19 May 2015, Ian Romanick wrote:
> From: Ian Romanick
>
> Currently on the functions that are exclusive to core-profile are
> implemented. The remainder continue to live in the XML. Additional
> functions can be moved later.
>
> The functions for GL_ARB_draw_indirect and GL_ARB_mult
On Thu, May 21, 2015 at 12:26 PM, Ben Widawsky wrote:
> A lot of opinion stuff is below, feel free to ignore them if you don't think
> there are improvements.
>
> On Fri, Apr 17, 2015 at 04:51:38PM -0700, Anuj Phogat wrote:
>> This patch enables using XY_FAST_COPY_BLT only for Yf/Ys tiled buffers.
On 05/21/2015 09:34 PM, Ilia Mirkin wrote:
Do the piglits currently fail? But this does seem right, although the
distinction between 64-bit and 32-bit queries is a *bit* unclear to me
(wrt the diff approaches the code takes).
I tested with the HUD and I compared results between NVA8 and NVD9.
Yeah, ARB_pipeline_statistics. HUD is a different use-case, hmmm...
perhaps it's forgetting to do something?
On Thu, May 21, 2015 at 3:43 PM, Samuel Pitoiset
wrote:
>
>
> On 05/21/2015 09:34 PM, Ilia Mirkin wrote:
>>
>> Do the piglits currently fail? But this does seem right, although the
>> dist
On 05/21/2015 09:33 PM, Ilia Mirkin wrote:
So... this doesn't fix a known issue? Just because nvc0 does
something, doesn't make it right. nvc0 has a ton of internal mp/pm
stats too, which are 64-bit, and provide other differences.
Sure, but in this case, it seems to fix the issue...
As an
Do the piglits currently fail? But this does seem right, although the
distinction between 64-bit and 32-bit queries is a *bit* unclear to me
(wrt the diff approaches the code takes).
On Thu, May 21, 2015 at 3:28 PM, Samuel Pitoiset
wrote:
> These queries use 64 bits. Tested on NVA8.
>
> Signed-of
So... this doesn't fix a known issue? Just because nvc0 does
something, doesn't make it right. nvc0 has a ton of internal mp/pm
stats too, which are 64-bit, and provide other differences.
As an aside, nv50_query_end for PIPE_QUERY_TIMESTAMP_DISJOINT *is*
busted... it sets q->ready = TRUE and then
A lot of opinion stuff is below, feel free to ignore them if you don't think
there are improvements.
On Fri, Apr 17, 2015 at 04:51:38PM -0700, Anuj Phogat wrote:
> This patch enables using XY_FAST_COPY_BLT only for Yf/Ys tiled buffers.
> Later It can be turned on for other tiling patterns (X,Y).
>
These queries use 64 bits. Tested on NVA8.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nv50/nv50_query.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c
b/src/gallium/drivers/nouveau/nv50/nv50_query.c
index a
According to nvc0, 64-bits queries use a fence to make sure
the result is available.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nv50/nv50_query.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, May 15, 2015 at 12:18:11PM -0700, Ian Romanick wrote:
> There are some really twitchy tests in ES1 (and possibly ES2)
> conformance related to this. Do any of those tests change with this commit?
I did run some ES1 conformnce tests, but the branches in the repo
were not very clear so I'm
On Fri, May 15, 2015 at 12:08:33PM -0700, Ian Romanick wrote:
> On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When rendering quad strips via tri strips we can't get the provoking
> > vertex right, so disallow flat shading.
>
> Same comments as for p
On Fri, May 15, 2015 at 12:07:54PM -0700, Ian Romanick wrote:
> On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We can allow rendering flat shaded polygons using tri fans if we check
> > the provoking vertex convention.
>
> This sounds reasonable sinc
On Thu, May 21, 2015 at 9:40 AM, Connor Abbott wrote:
> This is the second version of my dead control-flow series. In addition
> to fixing up a few things pointed out by Jason and cleaning up a few
> other odds and ends, I've fixed a number of bugs caught by disabling
> opt_if_simplification in GL
On Thu, May 21, 2015 at 12:54 PM, Matt Turner wrote:
> On Thu, May 21, 2015 at 9:40 AM, Connor Abbott wrote:
>> Before, when we were deleting a cf node that was a block, we were first
>> removing all the instructions and then calling cleanup_cf_node(), at
>> which point cleanup_cf_node() couldn't
On Thu, May 21, 2015 at 9:41 AM, Connor Abbott wrote:
> I'm not so sure about where to put the helper currently in nir.c... on
> the one hand, it's pretty specific to this pass, but on the other hand
> it needs to do some very fiddly low-level things to the control flow
> which is why it needs acc
On Thu, May 21, 2015 at 9:40 AM, Connor Abbott wrote:
> Before, we might have left dangling predecessors from jumps that were
> going to be removed.
>
> v2: split out from "nir: insert ssa_undef instructions when cleaning up
> defs/uses"
>
> Signed-off-by: Connor Abbott
> ---
> src/glsl/nir/
On Thu, May 21, 2015 at 9:40 AM, Connor Abbott wrote:
> Before, when we were deleting a cf node that was a block, we were first
> removing all the instructions and then calling cleanup_cf_node(), at
> which point cleanup_cf_node() couldn't do its job. Just move it before
> everything else, which s
This helps with testing the NIR dead cf pass.
Signed-off-by: Connor Abbott
---
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 be6713c..42e9b49 100644
--- a/src/glsl/glsl_p
v2: use nir_cf_node_remove_after().
v2: use foreach_list_typed() instead of hardcoding a list walk.
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir_opt_dead_cf.c | 123 ++---
1 file changed, 115 insertions(+), 8 deletions(-)
diff --git a/src/glsl/nir/nir_opt
We were already doing this internally for iterating over a function
implementation, so just expose it directly.
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir.c | 7 +++
src/glsl/nir/nir.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index
Doesn't do anything on the public shader-db.
Signed-off-by: Connor Abbott
---
src/glsl/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_nir.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index d784a81..7bdd895 100644
v2: fix detecting if the loop has any phi nodes after it.
v2: use nir_foreach_ssa_def() instead of nir_foreach_dest() when
checking for values live after the loop to catch const_load
instructions.
v2: fix handling return instructions
v2: add some documentation to loop_is_dead()
Signed-off-
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir.c | 16
src/glsl/nir/nir.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index 79c4a4a..cbee507 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -2242,6 +2242,22 @@ nir
Before, we might have left dangling predecessors from jumps that were
going to be removed.
v2: split out from "nir: insert ssa_undef instructions when cleaning up
defs/uses"
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
I'm not so sure about where to put the helper currently in nir.c... on
the one hand, it's pretty specific to this pass, but on the other hand
it needs to do some very fiddly low-level things to the control flow
which is why it needs access to a static function in nir.c
(stitch_blocks()) that I'd ra
When we deleted jumps like 'break' and 'continue,' we weren't removing
the phi sources that corresponded to them. Also, if we had a loop like
loop {
...
break;
}
and we deleted the break at the end because it was unreachable, we
wouldn't add an undefined source to the phi nodes at the begin
The point of cleanup_defs_uses() is to make an instruction safe to
remove by removing any references that the rest of the shader may have
to it. Previously, it was handling register use/def sets and removing
the instruction from the use sets of any SSA sources it had, but if the
instruction defined
This will be used in deleting unreachable control flow.
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir.c | 45 +
src/glsl/nir/nir.h | 3 +++
2 files changed, 48 insertions(+)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index bd4f6cc..0223
We were rewriting the uses of the intrinsic instruction to point to
something else after removing it, which only happened to work since we
were lax about having dangling uses when removing instructions. Fix that
up.
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir_lower_vars_to_ssa.c | 3 ++-
1
I found this useful while debugging some control flow bugs while working
on the dead control flow pass.
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir_validate.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.
This is the second version of my dead control-flow series. In addition
to fixing up a few things pointed out by Jason and cleaning up a few
other odds and ends, I've fixed a number of bugs caught by disabling
opt_if_simplification in GLSL IR as in the last patch. In particular,
patch 5 deals with r
Before, when we were deleting a cf node that was a block, we were first
removing all the instructions and then calling cleanup_cf_node(), at
which point cleanup_cf_node() couldn't do its job. Just move it before
everything else, which should be ok for the non-block case too.
v2: split out from pre
Fixed locally
On Wed, May 20, 2015 at 06:28:58PM -0700, Matt Turner wrote:
> On Wed, May 20, 2015 at 6:03 PM, Dylan Baker wrote:
> > Signed-off-by: Dylan Baker
> > ---
> > src/mapi/glapi/gen/gl_gentable.py | 29 +++--
> > 1 file changed, 15 insertions(+), 14 deletions(-)
Err, yes. Fixed.
On Wed, May 20, 2015 at 06:27:22PM -0700, Matt Turner wrote:
> > glapi: gl_procs.py: Fix a few long hanging style things
>
> s/long/low/ presumably
signature.asc
Description: Digital signature
___
mesa-dev mailing list
mesa-dev@lists.
When using SIMD4x2 on Skylake, the sampler instructions need a message
header to select the correct mode. This was added for most sample
instructions in 0ac4c2727 but the TXF_MCS instruction is emitted
separately and it was missed.
This fixes a bunch of Piglit tests which test texelFetch in a geom
https://bugs.freedesktop.org/show_bug.cgi?id=79706
--- Comment #2 from Emil Velikov ---
Actually I was contemplating on bringing back the "per release" regression
tracker idea which brought us here in the first place.
It will give us a clearer picture of the regressions when planning/doing the
r
On 05/16/2015 01:55 AM, Emil Velikov wrote:
On 09/04/15 16:05, Emil Velikov wrote:
Hi Boyan,
On 9 April 2015 at 16:08, Boyan Ding wrote:
For the same reason as the i965 one, as suggested by Chih-Wei Huang.
Cc: "10.4 10.5"
Signed-off-by: Boyan Ding
---
Did you run this and the i965 patch t
On 05/20/2015 06:56 PM, Dave Airlie wrote:
From: Dave Airlie
this fixes a build problem found on RHEL s390.
not sure what configure options caused it, I couldn't get it on
x86 here.
Cc: "10.6" mesa-sta...@lists.freedesktop.org
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/util/u_mat
https://bugs.freedesktop.org/show_bug.cgi?id=25898
--- Comment #6 from marius predut ---
I confirm that this app don't generate any errors. With or without proposed
defines the outputs are identical - see above comments.
--
You are receiving this mail because:
You are the QA Contact for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=25898
--- Comment #5 from marius predut ---
Created attachment 115947
--> https://bugs.freedesktop.org/attachment.cgi?id=115947&action=edit
app outputs
no matter if defines or not.
--
You are receiving this mail because:
You are the QA Contact for
On Thu, 2015-05-21 at 12:22 +0200, Alejandro Piñeiro wrote:
>
> On 20/05/15 23:39, Timothy Arceri wrote:
> > On Thu, 2015-05-14 at 22:49 +0200, Alejandro Piñeiro wrote:
> >> On 14/05/15 20:38, Ian Romanick wrote:
> >>>
> >>> I think I see what's happening. I don't think I understood
> >>> atomic.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello list,
The candidate for the Mesa 10.5.6 is now available. The current patch queue
is as follows:
- 30 queued
- 8 nominated (outstanding)
- and 1 rejected (obsolete) patches
The queue covers nearly every aspect of mesa - core mesa fixes, driv
On 20/05/15 23:39, Timothy Arceri wrote:
> On Thu, 2015-05-14 at 22:49 +0200, Alejandro Piñeiro wrote:
>> On 14/05/15 20:38, Ian Romanick wrote:
>>>
>>> I think I see what's happening. I don't think I understood
>>> atomic.buffer_index well enough when I removed it. :( In binding=3
>>> case, wh
99 matches
Mail list logo
