aboutsummaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorKenneth Graunke <[email protected]>2012-01-11 11:44:02 -0800
committerKenneth Graunke <[email protected]>2012-01-11 12:13:49 -0800
commit28cfa1fa213fe7ba6e5b57e61da663a6c3bf0c13 (patch)
tree58d5dfd1e22faee199976d3d5d2e77df72333dcf /include
parent10a6fde333f0170fbac70924581c647e531aba3e (diff)
i965: Don't reallocate push constant URB space on new VS programs.
The gen7_urb atom depends on CACHE_NEW_VS_PROG and CACHE_NEW_GS_PROG, causing gen7_upload_urb() to be called when switching to a new VS program. In addition to partitioning the URB space between the VS and GS, gen7_upload_urb() also allocated space for VS and PS push constants. Unfortunately, this meant that whenever CACHE_NEW_VS was flagged, we'd reallocate the space for the PS push constants. According to the BSpec, after sending 3DSTATE_PUSH_CONSTANT_ALLOC_PS, we must reprogram 3DSTATE_CONSTANT_PS prior to the next 3DPRIMITIVE. Since our URB allocation for push constants is entirely static, it makes sense to split it out into its own atom that only subscribes to BRW_NEW_CONTEXT. This avoids reallocating the space and trashing constants. Fixes a rendering artifact in Extreme Tuxracer, where instead of a snow trail, you'd get a bright red streak (affectionately known as the "bloody penguin bug"). This also explains why adding VS-related dirty bits to gen7_ps_state made the problem disappear: it made 3DSTATE_CONSTANT_PS be emitted after every 3DSTATE_PUSH_CONSTANT_ALLOC_PS packet. NOTE: This is a candidate for the 7.11 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38868 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions