summaryrefslogtreecommitdiffstats
path: root/VERSION
diff options
context:
space:
mode:
authorJason Ekstrand <[email protected]>2017-08-18 16:10:39 -0700
committerJason Ekstrand <[email protected]>2017-08-18 17:30:55 -0700
commitd5e217dbfda2a87e149bdc8586c25143fc0ac183 (patch)
tree1b884b4195e1260f06c61b63d86879e2dd6b13b8 /VERSION
parentbc56dfbf3f20504fce13e0f1730eea05ea0ea69a (diff)
i965: Stop looking at NewDriverState when emitting 3DSTATE_URB
Looking at NewDriverState is not safe in general. The state atom system is set up to ensure that new bits that get added to NewDriverState get accumulated into the set of bits used when emitting atoms but it doesn't go the other way. If we read NewDriverState, we may not get the full picture because the per-pipeline state (3D or compute) does not get added to NewDriverState before state emit is done. It's especially dangerous to do this from BLORP (either explicitly or implicitly when BLORP calls gen7_upload_urb) because that does not happen during one of the normal state upload paths. This commit solves the problem by whacking all of the per-shader-stage URB sizes to zero whenever we change the total URB size. We still have to flag BRW_NEW_URB_SIZE to ensure that the gen7_urb atom triggers but the actual decision in gen7_upload_urb can now be based entirely on URB sizes rather than on state atoms. This also makes BLORP correct because it just asks for a new URB config whenever the vsize is too small and so any change to the total URB size will trigger blorp to re-emit as well because 0 < vs_entry_size. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Bugzilla: https://bugs.freedesktop.org/102289 Cc: [email protected]
Diffstat (limited to 'VERSION')
0 files changed, 0 insertions, 0 deletions