| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
We've been referencing MRFs through the HW_REG file so far, but that
makes it harder to handle compute-to-MRF and similar optimizations.
|
|
|
|
|
| |
This will be used for compute-to-mrf, which needs to know when MRFs
get overwritten.
|
|
|
|
|
|
| |
These were copy and pasted from the FS, and are never used.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We generate silly code for array access, and it's easier to generally
support the cleanup than to specifically avoid the bad code in each
place we might generate it.
Removes 4.6% of instructions from 41.6% of shaders in shader-db,
particularly savage2/hon and unigine.
v2: Fixes by Ken: Make is_zero/one member functions, and fix a
progress flag.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
_NEW_WINDOW_POS wasn't a real Mesa state flag, but we were missing
_NEW_BUFFERS to update the stipple offset when FBO binding or window
size changed, and _NEW_POLYGON to update when stippling gets enabled.
Fixes oglconform's tristrip test.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Yuanhan Liu <[email protected]>
|
|
|
|
|
|
|
|
| |
Because we skip the pattern upload when stippling is disabled, we need
to check again when it might have been turned on.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Yuanhan Liu <[email protected]>
|
| |
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
ctx->Color.ColorLogicOpEnabled
Since GL_EXT_blend_logic_op is removed, _mesa_rgba_logicop_enabled(ctx)
just returns ctx->Color.ColorLogicOpEnabled. That seems kind of silly.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Since GL_EXT_blend_logic_op is removed, _LogicOpEnabled and
ColorLogicOpEnabled always have the same value.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When copy propagating a value into an instruction that negates its
argument, we need to invert the sense of the value's "negate" flag, so
that -(+x) becomes -x and -(-x) becomes +x.
Previously, we were always setting the value's "negate" flag to true
in this circumstance, so that both -(+x) and -(-x) turned into -x.
Fixes Piglit test vs-double-negative.shader_test.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
| |
We need to subclass swrast_texture_image because if we use swrast for
fallback rendering, we'll need to have swrast_texture_image objects.
|
|
|
|
|
|
| |
Matches the NewTextureImage() hook. With new subclasses of
gl_texture_image coming we need a new hook to properly delete objects of
those subclasses.
|
|
|
|
| |
It's only used by swrast now so move it out of core Mesa.
|
| |
|
|
|
|
|
|
|
|
| |
If we are called via the legacy DRI interface, and we don't support
legacy DRI (InitScreen is NULL), print a debug message, so it is easy
to see why the driver fails to initialize.
See https://bugs.freedesktop.org/show_bug.cgi?id=40437
|
|
|
|
|
|
|
|
|
| |
This introduces an UNCLAMPED_FLOAT_TO_UBYTE x 4 inline function, as
suggested by Brian. It uses it in a few places I noticed from previous
color changes, and also some core mesa places. I haven't updated other places
yet.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This introduces a new gl_color_union union and moves the current
ClearColorUnclamped to use it, it removes current ClearColor completely and
renames CCU to CC, then all drivers are modified to expected unclamped floats instead.
also fixes st to use translated color in one place it wasn't.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
The only purpose this call served in the DRI swrast driver was to
initialize the remap table. Core Mesa already does the dispatch
offset remapping for every function that could possibly ever be
supported. There's no need to continue using that cruft in the
driver.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Core Mesa already does the dispatch offset remapping for every
function that could possibly ever be supported. There's no need to
continue using that cruft in the driver.
Since the call to _mesa_enable_imaging_extensions (via
driInitExtensions) is removed, EXT_blend_color, EXT_blend_logic_op,
and EXT_blend_minmax are no longer advertised. These all resulted in
software fallbacks, so their loss will not be mourned.
EXT_blend_subtract is, however, explicitly added to the list.
GL_FUNC_SUBTRACT is fully accelerated, but GL_FUNC_REVERSE_SUBTRACT
(still) results in a software fallback.
Cc: Alex Deucher <[email protected]>
Cc: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Core Mesa already does the dispatch offset remapping for every
function that could possibly ever be supported. There's no need to
continue using that cruft in the driver.
Since the call to _mesa_enable_imaging_extensions (via
driInitExtensions) is removed, EXT_blend_color is explicitly added to
the list.
EXT_blend_logic_op is removed from the list of extensions because
blend factors and separate blend equations are not handled correctly.
Cc: Alex Deucher <[email protected]>
Cc: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Core Mesa already does the dispatch offset remapping for every
function that could possibly ever be supported. There's no need to
continue using that cruft in the driver.
Since the call to _mesa_enable_imaging_extensions (via
driInitExtensions) is removed, EXT_blend_color is explicitly added to
the list.
EXT_blend_logic_op is removed from the list of extensions because
blend factors and separate blend equations are not handled correctly.
Based on feedback from Roland Scheidegger.
Cc: Dave Airlie <[email protected]>
Cc: Alex Deucher <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: Corbin Simpson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Core Mesa already does the dispatch offset remapping for every
function that could possibly ever be supported. There's no need to
continue using that cruft in the driver.
Since the call to _mesa_enable_imaging_extensions (via
driInitExtensions) is removed, EXT_blend_color is explicitly added
with a dependency on the drmSupportsBlendColor flag.
EXT_blend_logic_op is removed from the list of extensions because
blend factors and separate blend equations are not handled correctly.
Based on feedback from Roland Scheidegger.
Cc: Alex Deucher <[email protected]>
Cc: Dave Airlie <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Core Mesa already does the dispatch offset remapping for every
function that could possibly ever be supported. There's no need to
continue using that cruft in the driver.
Since the call to _mesa_enable_imaging_extensions (via
driInitExtensions) is removed, EXT_blend_color, EXT_blend_minmax, and
EXT_blend_subtract are explicitly added to the list.
EXT_blend_logic_op is removed from the list of extensions because
blend factors and separate blend equations are not handled correctly.
Cc: Ben Skeggs <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
Cc: Viktor Novotný <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Core Mesa already does the dispatch offset remapping for every
function that could possibly ever be supported. There's no need to
continue using that cruft in the driver.
EXT_blend_logic_op is removed from the list of extensions because
blend factors and separate blend equations are not handled correctly.
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Not all drivers use ctx in LOCAL_VARS, so '(void) ctx;' is added to
all the function templates to make GCC happy.
|
| |
|
| |
|
|
|
|
| |
The parameters can't be removed because they are part of the DRI ABI.
|
|
|
|
|
|
|
|
|
|
|
| |
expression < 0 is always false"
The test was of an enum, attIndex, which should be unsigned. The
explicit check for < 0 was replaced with a cast to unsigned in an
assertion that attIndex is less than the size of the array it will be
used to index.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
Trivially silence the compiler by adding '(void) foo;' for each unused
parameter. These parameters could not be removed. They are part of
interface used elsewhere in Mesa, and some of the other customers
actually use these parameters.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The internalFormat, format, and type parameters were not used by
either try_pbo_upload or try_pbo_zcopy, so remove them. The width
parameter was also not used by try_pbo_zcopy (because it doesn't
actually copy anything), so remove it too.
Eric Anholt notes:
The current structure of this code is so hateful I can't bring
myself to say anything about whether changing the current code is
good or bad.
I have a dream that one call would try to make a surface
(miptree/region) out of the PBO, then we'd see about whether it
matches up nicely and zero-copy/blit using that. That would be
reusable for texsubimage, which is currently awful in this
respect.
At some point we should revisit this code with pitchforks and torches.
|
|
|
|
|
|
|
|
|
|
| |
The depth0 parameter was not used in intel_miptree_create_for_region,
so remove it. All of the places that call this function, pass 1 for
that parameter, and the place where it looks like it should have been
used (the call to intel_miptree_create_internal) also had 1 hard
coded.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The GLenum target parameter was not used in intel_copy_texsubimage, so
remove it. Also remove the GLenum internalFormat parameter. Each
caller just copied this out of the intel_texture_image that is already
passed to intel_copy_texsubimage.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
| |
The intel_context and tiling parameters were not used by any if the
i9[14]5_miptree_layout or the functions they call, and the tiling parameter was
not used by brw_miptree_layout. Remove the unnecessary parameters.
|
|
|
|
|
|
| |
The gl_framebuffer was not used in intel_draw_buffer, so remove it.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
| |
The intel_context was not used in any of these functions, so remove it.
|
|
|
|
|
|
|
|
|
| |
Also clean-up some of the naming, etc. in
intel_buffer_object_purgeable. 'intel' is usually used as the name of
an intel_context pointer, and intel_obj is usually used as the name of
an intel_*_obj pointer. These changes were suggested by Eric Anholt.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
signed and unsigned integer expressions"
v2: Remove the assertion in intel_batchbuffer_space:
assert((intel->batch.state_batch_offset - intel->batch.reserved_space)
>= intel->batch.used*4);
After reviewing all the places where this is called, I'm (fairly)
comfortable that this assertion was redundant. Having the assertion
adds ~20KiB to a driver build:
text data bss dec hex filename
903173 26392 1552 931117 e352d i965_dri.so
924093 26392 1552 952037 e86e5 i965_dri.so
Based on feedback from Eric Anholt.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
This was missed back when the target parameter was removed from all
the buffer-related driver hooks.
|
|
|
|
|
| |
Further reduces instruction count by 4.0% in 40.7% of the vertex
shaders.
|
|
|
|
|
| |
This only occurs for GRFs, and hasn't mattered until now because we
only copy propagated non-GRFs.
|
|
|
|
| |
Removes 2.0% of the instructions from 35.7% of vertex shaders in shader-db.
|
|
|
|
|
|
|
|
|
|
|
| |
This differs from the FS in that we track constants in each
destination channel, and we we have to look at all the swizzled source
channels. Also, the instruction stream walk is done in an O(n) manner
instead of O(n^2).
Across shader-db, this reduces 8.0% of the instructions from 60.0% of
the vertex shaders, leaving us now behind the old backend by 11.1%
overall.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tracking virtual GRFs has tension between using a packed array per
virtual GRF (which is good for register allocation), and sparse arrays
where there's an element per actual register (so the first and second
column of a mat2 can be distinguished inside of an optimization pass).
The FS mostly avoided the need for this second sparse array by doing
virtual GRF splitting, but that meant that instances where virtual GRF
splitting didn't work, instructions using those registers got much
less optimized.
|