The GLES blob on the p3a limits constlen to 512 between VS and FS across
a6xx gpu ids (615, 630, 640, and 650). Experimentally, exceeding that
limit in any one stage results in rendering corruption or GPU hangs
(though my most detailed testing had a loop limit in a uniform, so that
may the cause of the hang). Clamp the limit we use inside of a shader so
we don't exceed it within a stage.
This commit doesn't resovle limiting inter-stage. Experimentally, I've
found that I can push up to a total of ~768 vec4s between VS and FS on
a630, with or without uniform updates between each draw. We'll need to do
some shader key-based limiting of constlen at draw time to respect that
limit, but that's left for future work, and this commit is enough for the
google earth case that initiated this work.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5273>
It turns out the GL uniforms file is larger than the hardware constant
file, so we need to limit how many UBOs we lower to constbuf loads. To do
actual UBO loads, we'll need to be able to upload UBO 0's pointer or
descriptor.
No difference on nohw 1 UBO update drawoverhead case (n=35).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5273>
For now we never ask to set up UBO 0 as a real UBO, so this doesn't
trigger, but it gets us ready for handling the case where UBO 0 is too big
to be push constants in the HW.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5273>
Comparing a blob trace using the feature to one not, the difference was
pretty obvious and in the spot you'd expect compared to alphaToCoverage.
The SP_ reg didn't have a corresponding bit set, though it also has an
alphaToCoverage.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5343>
The script was failing for me (python 3.8), not sure if this is a recent
python version break or not as I don't know how often people have been
running this script:
Processing ./gen9.xml... Traceback (most recent call last):
File "./gen_sort_tags.py", line 177, in <module>
main()
File "./gen_sort_tags.py", line 170, in main
genxml[:] = enums + sorted_structs.values() + instructions + registers
TypeError: can only concatenate list (not "odict_values") to list
Turning the odict into a list fixes it for me, and the resulting xml
file are identical to before :)
Fixes: 903e142f0d ("genxml: add a sorting script")
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5352>
This is a squash commit of in house performance fixes and misc bug fixes
for GL4.1 support.
Performance fixes:
* started using system memory for constant buffer to gain 3X performance boost with metro redux
Misc bug fixes:
* fixed usage of vertexid in shader
* added empty control point phase in hull shader for zero ouput control point
* misc shader signature fixes
* fixed clip_distance input declaration
* clearing the dirty bit for the surface while using direct map if surface is already flushed
and there is no pending primitive
This patch also uses SVGA_RETRY macro for commands retries. Part of it is already
used in previous patch.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Signed-off-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5317>
This patch adds the following tgsi utilities
* tgsi_dynamic_indexing: This utility flattens out the dyanamic indexing of constant buffers
* tgsi_vpos: This utility writes zeros to position at index 0 in vertex shader.
This utility can be used if there is no shader output in vertex shader
* util_make_tess_ctrl_passthrough_shader: This adds passthough tessellation control shader.
Input of passthrough tess ctrl shader is output of vertex shader
and output is input of tessellation eval shader.
If program has tessellation eval shader but no tessellation control shader,
this utility can be used to create passthrough tessellation control shader.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Signed-off-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5317>
Technically we only have to do late-z in the alpha-test or discard case
if depth-write is enabled. If depth write is disabled, the depth read /
test / conditional-write interlock that we need to emulate is not a
problem, so we can still use early-z test.
There is a slightly weird case when there is no zsbuf attachment (see
dEQP-GLES31.functional.fbo.no_attachments.*) where the hw wants us to
use LATE_Z.. not entirely sure if this is an interaction with occlusion
query or just a pecularity of how the hw works when there is no depth
buffer.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5336>
We were remapping the bindings so the HW binding points were consecutive,
which there's no need for. Now that we don't shuffle, we can mostly drop
the dependency on the pipeline for this SDS.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5321>
the virgl CI code was using the noopt path and crashing with a
wierd can't select llvm.coro.subfn.addr error, turns out we have
to call the cleanup pass no matter what.
This enable a lot more virgl gles31 passes, but we have
to disable tessellation shaders as now they executed, they
crash due to missing OES_gpu_shader5, I should try and reenable
them when llvmpipe is further along
Fixes: d32690b43c ("gallivm: add coroutine pass manager support")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Acked-by: Elie Tournier <elie.tournier@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5320>
The FETCH_CNT field isn't actually the FETCH count. We don't have a
lot of data where it's different from DECODE_CNT, so there's not much
to go by. It could be number of VFD_DEST_CNTL or maybe DECODE_CNT for
binning. For now, setting both to number of DEST_CNTL gets Google
Earth working again.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5324>
Icecream95