__next and __prev are pointers to the structure containing the exec_node
link, not the embedded exec_node. NULL checks would fail unless the
embedded exec_node happened to be at offset 0 in the parent struct.
v2: Jason Ekstrand <jason.ekstrand@intel.com>:
Use "(__node)->__field.next != NULL" to check for the end of the list
instead of the "&__next->__field != NULL". The former is far more
obviously correct as it matches what the non-safe versions do. The
original code tried to avoid any use of __next as the client code may
delete it during its execution. However, since the looping condition is
checked after the iteration clause but before the client code is
executed, we know that __node is valid during the looping condition.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(Jason noted that this is not a good long term solution, and we should
instead improve nir_lower_io so that this extra set of MOVs is
unnecessary. I tend to agree, but decided we could do that as a
follow-up improvement.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
No functional change. In preparation for supporting vertex shaders,
this adds a switch statement on shader stage (since vertex attributes
and fragment shader varyings will need different handling). It also
renames "varying" to "input", to be more general.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Ian and I added these around the time Connor was developing NIR. Now
that both exist, we should make them work together!
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
We can't safely call nir_optimize() with register present, since several
passes called in the loop can't handle registers, and will fail asserts.
Notably, nir_lower_vec_alus() and nir_opt_algebraic() really don't want
registers.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Array variable copy splitting generates a bunch of stuff we want to
clean up before proceeding.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
The NIR backend hardcodes brw_wm_prog_key at the moment, which won't
work when we support scalar VS. We could use get_tex(), but it's a
static method. I was going to promote it to fs_visitor, but then
realized that both parameters (stage and key) are already members.
It then occured to me that we could just set up a pointer in the
constructor, and skip having a function altogether.
This patch also converts all existing users to use key_tex.
v2: Make key_tex a "const brw_sampler_prog_key_data *" instead of
non-const; word-wrap some lines. (Review comments from Topi.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
_BLENDAPI boils down to __cdecl on Windows, but __cdecl is the default
calling convention so this serves no purpose.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
std::unique_ptr takes ownership of MM, and a double delete could ensure
in case of an error, as pointed out by Chris Vine in
https://bugs.freedesktop.org/show_bug.cgi?id=89387
Reviewed-by: Chris Vine <chris@cvine.freeserve.co.uk>
By passing --force autoreconf will update all the aux files, which would
otherwise be ignored if one updates autoconf/automake.
Quote the ORIGDIR variable to prevent fall-outs, when its name contains
space.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Implicitly required for a while, although commit 9385c592c6 (mapi:
remove u_thread.h) was the one that put the final nail on the
coffin.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Left over from commit 18db13f5865(mapi: THREADS was always defined,
remove it)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This has been an implicit rule for building mesa for a long time. Let's
make it official and just bail out at configure time. This way we can
cleaning up some of our glx code.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Convert the code to use the C11 threads implementation, and nuke the
Windows non-pthreads code-path. The c11/threads_win32.h abstraction
should be better than the current code.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Brian Paul review suggestion: there's more macro use here than necessary.
Removed and redefine some #define preprocessing directives.
Removed the directive input parameter 'T' .
No functional changes.
Signed-off-by: Marius Predut <marius.predut@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
We were already using strdup() in various places in Mesa. Get rid
of the _mesa_strdup() wrapper. All the callers pass a non-NULL
argument so the NULL check isn't needed either.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The piglit test glsl-fs-uniform-array-loop-unroll.shader_test was designed
to do an out of bounds access into an uniform array to make sure that we
handle that situation gracefully inside the driver, however, as Ken describes
in bug 79202, Valgrind reports that this is leading to an out-of-bounds access
in fs_visitor::demote_pull_constants().
Before accessing the pull_constant_loc array we should make sure that
the uniform we are trying to access is valid.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79202
Reviewed-by: Matt Turner <mattst88@gmail.com>
Same idea as this patch, only for gen6_gs_visitor:
commit 49a938a265
Author: Jordan Justen <jordan.l.justen@intel.com>
Date: Fri Feb 20 12:12:25 2015 -0800
i965/fs: Use fs_reg for CS/VS atomics pixel mask immediate data
Suggested-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
brw_imm_ud(0xffff) should have been converted to fs_reg(0xffffu) to
make sure the uint32_t fs_reg constructor was matched.
commit 49a938a265
Author: Jordan Justen <jordan.l.justen@intel.com>
Date: Fri Feb 20 12:12:25 2015 -0800
i965/fs: Use fs_reg for CS/VS atomics pixel mask immediate data
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We now skip allocating a hiz miptree for gen8. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
v2:
* Update hz_height calculation as suggested by Topi
v3:
* Bail if we failed to create the bo (Ben)
v4:
* CEILING => DIV_ROUND_UP
* Make sure mt->logical_depth0 being 0 would not cause trouble
* Fail if Y tiling is not returned
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67564
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
v2:
* Update hz_height calculation as suggested by Topi
v3:
* Bail if we failed to create the bo (Ben)
v4:
* CEILING => DIV_ROUND_UP
* Make sure mt->logical_depth0 being 0 would not cause trouble
* Fail if Y tiling is not returned
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67564
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Today we allocate a miptree's for the hiz buffer. We needed this in
the past because we would point the hardware at offsets of the hiz
buffer. Since the hiz format is not documented, this is not a good
idea.
Since moving to support layered rendering on Gen7+, we no longer point
at an offset into the buffer on Gen7+.
Therefore, to support hiz on Gen7+, we don't need a full miptree
structure allocated.
This patch starts to create a new auxiliary buffer structure
(intel_miptree_aux_buffer) that can be a more simplistic miptree
side-band buffer associated with a miptree. (For example, to serve the
needs of the hiz buffer.)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
The maximum value of a Gallium HUD's panel is automatically adjusted
when the current value is greater than the max. If we set the
pipe_query_driver_info::max_value to UINT64_MAX, the maximum value is
never adjusted and this results in a flat line instead of a pretty curve
which is correctly scaled.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
brw_shader.cpp: In function ‘bool brw_saturate_immediate(brw_reg_type, brw_reg*)’:
brw_shader.cpp:618:31: warning: ‘sat_imm.brw_saturate_immediate(brw_reg_type, brw_reg*)::<anonymous union>::ud’ may be used uninitialized in this function [-Wmaybe-uninitialized]
reg->dw1.ud = sat_imm.ud;
^
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
i915_fragprog.c: In function ‘i915ValidateFragmentProgram’:
i915_fragprog.c:1453:11: warning: variable ‘k’ set but not used [-Wunused-but-set-variable]
int k;
^
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
It looks like this has existed since
commit f5a477ab76
Author: Ian Romanick <ian.d.romanick@intel.com>
Date: Mon Dec 16 11:54:08 2013 -0800
meta: Refactor shader generation code out of mipmap generation path
Valgrind was complaining on fbo-generatemipmap-formats
v2: Instead, do the allocation after the early return block (v2)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
