| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Was missed in an earlier renaming patch.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
| |
To be a little more understandable.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An assert is currently raised, preventing decompression of a texture image into
a GL_TEXTURE_3D target. I have not found any spec wording that would explain
this, or implementation detail that would prevent it. And in any case, the
driver should not cause a crash upon user input arguments.
Fixes most failing subcases in CTS tests:
* GL44-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
* GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
These tests were crashing the driver before. Now they just fail, but due
to an unrelated issue affecting 2 out of the 45 test subcases.
No regressions observed against piglit or CTS-GL.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
These restrictions existed because intel_miptree_blit couldn't handle
surfaces bigger than 32k. How that we're chopping blits up into chunks, it
can handle any size we throw at it so we can get rid of this restriction.
This improves the terrain tests in synmark by 25-30% on my Sky Lake gt3.
Signed-off-by: Jason Ekstrand <[email protected]>
Reported-by: Ben Widawsky <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to blit much larger images than if we use the blitter
directly. In particular, it gives us an almost infinite image height
compared to the fairly limiting 32k. We do, however, still have a
restriction on stride of the image because handling larger strides, while
possible, is fairly difficult.
v2: Properly handle linear blit alignment restrictions
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: Properly handle linear blit alignment restrictions
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This assertion, while valid for linear buffers, doesn't work properly for
tiled memory. It used to work most of the time because the offset provided
was always to the left-hand edge of the image. However, if you use a byte
offset to get to the inside of the image, the height * stride calculation
may actually end up being too large.
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The only actual user of this parameter was blorp and, since the conversion
to ISL, it no longer uses this function.
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So that it has the same semantics as the scalar backend implementation. The
helper will now take a simd width (which is always 8 in vec4 mode) and step
as many scalar components as specified by that width, respecting the size of
the scalar channels.
v2 (Curro):
- Remove the assertion in offset(), byte_offset() has the same checks.
- Use byte_offset() directly instead of add_byte_offset().
- Make things more clear by explicitly including the vertical stride
in the byte offset expression.
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
In a later patch we want to change the semantics of offset() to be in terms
of SIMD width and scalar channels so it is consistent with the definition
of the same helper in the scalar backend. However, some uses of offset()
in the vec4 backend do not operate naturally in terms of these
semantics. In these cases it is more natural to use the byte_offset() helper
instead.
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: wrap the helper in a namespace to make clear that it is an
implementation detail of byte_offset() and is not intended
to be used independently (Curro).
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes 8 failing dEQP tests:
dEQP-EGL.functional.create_context_ext.robust_gles*
(now 42 tests pass in dEQP-EGL*robust*, 0 fail and rest are skipped)
Signed-off-by: Tapani Pälli <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98343
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
| |
commit 85008db1d51f923113832394d7f8d6b1868be882 missed this enum
for GL_KHR_robustness implementation
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
so->fence can be unreferenced by one thread while another thread is
somewhere in ClientWaitSync and expecting so->fence to be non-NULL.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98172
Cc: 12.0 13.0 <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
| |
It's the same as st_client_wait_sync. Discovered by Michel.
This is needed to make the following fix simpler.
Cc: 12.0 13.0 <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This function allows to modify an existing symbol.
v2:
- Remove namespace usage now that it was deleted.
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of 59864e8e020 we just use the location assigned by the front-end and
no longer need this for i965.
Since there were some issues in the logic with assigning arrays the same
driver location if they didn't start at the same location just remove it
and let other drivers implement a solution if needed when they add
ARB_enhanced_layouts support.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
This temporary helper is no longer needed now that we have finished
refactoring common shader metadata.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
And set system values read directly in shader_info.
st/mesa changes where:
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
And set outputs written directly in shader_info.
st/mesa changes where:
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
And set set inputs_read directly in shader_info.
To avoid regressions between changes this change is a squashed
version of the following patches.
st/mesa changes where:
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
| |
_mesa_copy_linked_program_data()
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Here we move OriginUpperLeft and PixelCenterInteger into gl_program
all other fields have been replace by shader_info.
V2: Don't use anonymous union/structs to hold vertex/fragment fields
suggested by Ian.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
| |
Note we access shader_info from the program struct rather than the
nir_shader pointer because shader cache won't create a nir_shader.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
Rather then messing around creating bitfields and arrays to store
the interpolation location just translate it on the fly.
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This was accidently disabled in 832bcc3613 not long after it was added.
Since it's only for gen5 and lower we might as well just remove it rather
than fixing it.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here brw_setup_vue_interpolation() is rewritten not to use the InterpQualifier
array in gl_fragment_program which will allow us to remove it.
This change also makes the code which is only used by gen4/5 more self contained
as it now has its own gen5_fragment_program struct rather than storing the map
in brw_context. This means the interpolation map will only get processed once
and will get stored in the in memory cache rather than being processed everytime
the fs changes.
Also by calling this from the fs compile code rather than from the upload code
and using the interpolation assigned there we can get rid of the
BRW_NEW_INTERPOLATION_MAP flag.
It might not seem ideal to add a gen5_fragment_program struct however by the end
of this series we will have gotten rid of all the brw_{shader_stage}_program
structs and replaced them with a generic brw_program struct so there will only
be two program structs which is better than what we have now.
V2: Don't remove BRW_NEW_INTERPOLATION_MAP from dirty_bit_map until the following
patch to fix build error.
V3 - Suggestions by Jason:
- name struct gen4_fragment_program rather than gen5_fragment_program
- don't use enum with memset()
- create interp mode set helper and simplify logic to call it
- add assert when calling function to show prog will never be NULL for
gen4/5 i.e. no Vulkan
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
A following patch is going to merge the gl_fragment_program struct into
a common gl_program and we want to avoid all stages having this array.
V2: use TGSI_INTERPOLATE_COUNT as the temporary placeholder. Suggested by
Marek.
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
| |
InterpQualifier is never set for ARB programs so this will do nothing.
Reviewed-by: Jason Ekstrand <[email protected]>
|