Looks like a copy and paste error from f752effa08
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
swr rasterizer contains numerous data transfers between vectors
and ordinary C types. Fixing for strict aliasing will take time.
Reviewed-by: Matt Turner <mattst88@gmail.com>
AST_NUM_OPERATORS stores the dimension of the ast_operators
enumeration but was not updated after its last modification.
This doesn't add any real modification for any code paths but it makes
sense for coherence.
v2 (Eric Engestrom): Just place the define at the end of the
enumeration, not below.
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Once upon a time (commit 8313f44409) Paul added code for the unlit
centroid workaround (WaCopyUnlitCentroidBarys). His commit message
claims it fixed the EXT_framebuffer_multisample/interpolation {2,4}
{centroid-deriv,centroid-deriv-disabled} piglit tests but does not say
on which platform, though he cites the IVB PRM.
"3DSTATE_WM [DevIVB, DevHSW]" says
"[DevIVB]: Workaround: When Centroid Barycentric mode is required, HW
may produce incorrect interpolation results when a 2X2 pixels have
unlit pixels."
I later disabled it for Haswell (commit f6db414f3c) with no known ill
effects.
The Sandybridge page does not have this text, but the workarounds
database (see WaCopyUnlitCentroidBarys) says the issues applies *only*
to Sandybridge, and in fact in commit 1a2de7dce8 I note that disabling
the workaround on Sandybridge causes the tests Paul originally mentioned
to fail.
So this is, and always has been, a huge confusing mess.
Disabling the workaround indeed causes the tests Paul originally
mentioned to fail on Sandybridge but not on Ivybridge/Baytrail.
On Ivybridge:
total instructions in shared programs: 6914901 -> 6909599 (-0.08%)
instructions in affected programs: 106766 -> 101464 (-4.97%)
helped: 884
total cycles in shared programs: 70874764 -> 70813774 (-0.09%)
cycles in affected programs: 794144 -> 733154 (-7.68%)
helped: 688
HURT: 186
LOST: 1
GAINED: 6
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
it cut off the upper 32 bits
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Improves performance of OglBatch7 by 4.06851% +/- 1.17925% (n=169) on
Haswell, and cuts ~18k of .text:
text data bss dec hex filename
5824627 287816 29384 6141827 5db783 before/i965_dri.so
5806354 287816 29384 6123554 5d7022 after/i965_dri.so
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This can be used by the driver to get the command line which started
the process. Will be used by the VMware driver for extra logging.
For now, this is only implemented for Linux via /proc/self/cmdline
and Windows via GetCommandLine().
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch eliminates the redundant SetVertexBuffers and
SetIndexBuffer commands that are emitted for rebind purpose.
With this patch, the set commands will be skipped, but we will still
reference the associated resources to allow the kernel to
bring in the resources.
Tested with Lightsmark2008, Valley, MTT glretrace, piglit, conform.
Reviewed-by: Brian Paul <brianp@vmware.com>
There are cases where we hit u_vbuf path due to alignment or pitch-
alignment restrictions, but for an output-format that u_vbuf does not
support translating (yet the driver does support natively). In which
case we hit the memcpy() path and don't care that u_vbuf doesn't
understand it.
Fixes crash with debug build of mesa in:
dEQP-GLES3.functional.vertex_arrays.single_attribute.strides.fixed.user_ptr_stride17_components2_quads1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95000
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
AFAICT, it's never been used.
It was briefly nudged in the right direction here:
commit 10e5ffd496
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date: Sat Jan 25 17:19:10 2014 +0000
gbm: do not export _gbm_mesa_get_device
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
The field is only read for printing today and
there it was probably a leftover.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
The way it is used today does not care about the
Enabled flag anymore.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Instead of gl_client_array::Enabled inside a VAO,
directly use the gl_vertex_attrib_array::Enabled value
which is the origin of the above.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Only a debugging function, but move away from
gl_client_array and use the first order information
from the VAO.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Only a debugging function, but move away from
gl_client_array and use the first order information
from the VAO. Also make use of gl_vert_attrib_name.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Only a debugging function, but move away from
gl_client_array and use the first order information
from the VAO. Also make use of gl_vert_attrib_name.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Similarily to _mesa_all_varyings_in_vbos walk the VAO
to check if we have an illegal mapped buffer object
instead of walking all gl_client_arrays.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
In vbo_draw_transform_feedback we currently look at
exec->array.inputs to determine if all varying
vertex attributes reside in vbos. But the vbo_bind_arrays
call only happens past the vbo_all_varyings_in_vbos
query. Thus we may work on a stale set of client arrays.
Using the current VAOs content for this query feels much
more logical to me.
Additionally with this change mesa makes more use of the
information already tracked in the VAO instead of looping
across VERT_ATTRIB_MAX vertex arrays.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Implement the equivalent of vbo_all_varyings_in_vbos for
vertex array objects.
v2: Update comment.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
When a vertex buffer object gets deleted, it is unbound
at the VAO. To do this use _mesa_bind_vertex_buffer instead
of plain unreferencing the buffer object. This keeps the VAOs
internal state consistent. In this case it showed up with
gl_vertex_array_object::VertexAttribBufferMask getting out of
sync.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
This was added with ARB_enhanced_layouts.
V2: Add an extra format specifier for the new qualifier.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
See commit b0629e6894, where we discovered
that the SOL stage's "Rendering Disable" feature is a lot faster at
throwing away all geometry than the clipper's "reject all" mode.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
CovID: 401540
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Previously, the bitshift would be performed on a simple int (32 bits on
most systems), overflow, and then be cast to 64 bits.
CovID: 1362461
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We need to emit RB_FRAME_BUFFER_DIMENSION once per batch.. tracking this
in fd_context is wrong when the gmem code executes asynchronously from
the flush_queue worker. But in fact we don't really need to track it at
all. We cannot assume previous value at the beginning of the batch
(because of other processes potentially using the GPU), so just drop the
tracking and emit it in _tile_init().
Signed-off-by: Rob Clark <robdclark@gmail.com>
This is also used in gmem code, which executes from the "bottom half"
(ie. from the flush_queue worker thread), so it cannot be in fd_context.
Signed-off-by: Rob Clark <robdclark@gmail.com>
