V2: Set force_writemask_all on ADD; this *is* necessary in the VS case
too.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For now, assume that the addressed sampler can be in any of the
16-sampler banks. If we preserved range information this far, we
could avoid emitting these instructions if the sampler were known
to be contained within one bank.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We're about to be using this infrastructure to build descriptors in
src1 of non-send instructions, when preparing to do an indirect send.
Don't accidentally clobber the conditionalmod field of those
instructions with SFID bits, which aren't part of the descriptor.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
This provides a reasonable place to enforce the hardware restriction
that indirect descriptors must be in a0.0
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
The pass breaks live ranges of virtual registers by allocating new
registers when it sees an assignment to a virtual GRF it's already seen
written.
total instructions in shared programs: 4337879 -> 4335014 (-0.07%)
instructions in affected programs: 343865 -> 341000 (-0.83%)
GAINED: 46
LOST: 1
[mattst88]: Make pass not break in presence of control flow.
invalidate_live_intervals() only if progress.
Fix up delta_x/delta_y.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Commit c66d928f2c ("i965: Enable INTDIV
in SIMD16 mode.") began using generate_math_gen6 to break SIMD16 INTDIV
into two SIMD8 operations.
generate_math_gen6 takes two registers - for unary operations, we pass
ARF null for the second operand. Prior to Broadwell, real operands were
always GRF. But now they can be IMM as well.
So, check for != ARF instead of == GRF.
+12 piglits.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This reverts commit af13cf609f, which
appears to cause huge performance problems on Ivybridge. I'd missed
that the FFTID bits are in the low byte. The documentation doesn't
indicate that the URB write message header actually wants FFTID - it
just labels those bits as "Reserved." But it appears necessary.
This does slightly more than revert the original change: originally,
Broadwell had separate code generation, which used MOV, and this patch
only changed it for Gen4-7. Now that both are unified, reverting this
also makes Broadwell use OR. Which should be fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The extension says GL 4.0 is required. We'll meet the spirit
of that restriction by enabling on just those generations which will
soon support GL 4.0 (Gen7+), although it's technically supportable on
all generations.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The quality level (fine/coarse/dont-care) is plumbed through to the
generator as a constant in src1.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The quadop-based method we currently use on all chipsets already
provides the fine version of the derivatives.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Reviewed-by: Roland Scheidegger <sroland@vmware.com> (v1)
v2: Reuse opcode gaps as suggested by Marek
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This extension is identical to NV_texture_barrier. Alias
glTextureBarrier to the existing glTextureBarrierNV and use the existing
NV_texture_barrier extension bit.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This matches the name of the dd hook. Also convert a couple of nearby
dd implementations to lowercase + underscore as is now the standard.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Right now we decide which kernels to use and the GRF start offsets in
one place and emit the kernel pointers later. The logic of how to map
8, 16 and 32 kernels to kernel start pointers follows the same logic as which
GRF start offsets to use, so lets figure out these two things in one place.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
This maintains a list of all TBOs in a pipe_context.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The EGL_EXT_image_dma_buf_import specification was revised (according to
its revision history) on Dec 5th, 2013, for EGL to not take ownership of
the file descriptors.
Do not close the file descriptors passed in to eglCreateImageKHR with
EGL_LINUX_DMA_BUF_EXT target.
It is assumed, that the drivers, which ultimately process the file
descriptors, do not close or modify them in any way either. This avoids
the need to dup(), as it seems we would only need to just close the
dup'd file descriptors right after.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76188
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
gcc 4.6.3 chokes with the following error:
brw_vec4.cpp: In member function 'int brw::vec4_visitor::setup_uniforms(int)':
brw_vec4.cpp:1496:37: error: expected primary-expression before '.' token
Apparently C++ does not do named initializers for unions, except maybe
as a gcc extension, which is not present here.
As .f is the first element of the union, just drop it. Fixes the build
error.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Matt Turner <mattst88@gmail.com>
* --enable-{32,64}-bit is done. Use --build and --host instead.
* Configure does not add "-g -O2" to C{,XX}FLAGS.
* Pkg-config has been mandatory for a while now.
* Avoid using LDFLAGS, refer to pkg-config.
* --with-expat is deprecated. Use pkg-config.
v2:
* Note that CC/CXX will need to be set for multilib builds.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
The SCons documentation is not explicit on the topic yet building mesa
with SCons and MSVC is known to have problems when headers are listed.
So be safe just drop them for now.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82534
Tested-by: Vinson Lee <vlee@freedesktop.org>
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
These two were added ages ago, with an explicit comment "Hacks ..."
They have been insufficient for years and maintainers needed to
explicitly handle the build themselves.
Rather than lying and pretending that it works, just kill this hack and
let maintainers build things the way it should be done for their
distribution.
Document the removal in the release notes.
Suggested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This reverts commit 2af28040d6.
The commit was resolving an issue where libtool will not setup the
environment correctly when one explicitly provides --enable-{32,64}-bit
at configure time. It was caused due to the "-m32,64" C{,XX}FLAGS being
set too late relative to LT_INIT.
At the same time this cases the enable_static to be incorrectly set,
amongst others leading to build issues. Rather than being smart and
trying to handle 32/64 bit build ourselves it may be better to delegate
it to the builder/maintainer. The latter should now know better which is
the correct(most appropriate) method.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82536
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82546
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>
The brw_stage_prog_data struct previously contained an array of float pointers
to the values of parameters. These were then copied into a batch buffer to
upload the values using a regular assignment. However the float values were
also being overloaded to store integer values for integer uniforms. This can
break if x87 floating-point registers are used to do the assignment because
the fst instruction tries to fix up invalid float values. If an integer
constant happened to look like an invalid float value then it would get
altered when it was copied into the batch buffer.
This patch changes the pointers to be gl_constant_value instead so that the
assignment should end up copying without any alteration. This also makes it
more obvious that the values being stored here are overloaded for multiple
types.
There are some static asserts where the values are uploaded to ensure that the
size of gl_constant_value is the same as a float.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81150
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes an issue with flash where it tries to destroy a decoder
after already destroying the device associated with the decoder.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82517
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
