KonstantinSeurer
/
mesa
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

i965: Fix BRW_VARYING_SLOT_PAD handling in the scalar VS backend. 

We can't just break for padding slots.  Instead, treat them like
unwritten output variables, so we handle flushing and incrementing
urb_offset correctly.

Paul introduced the concept of padding slots back in 2011, but we've
never actually used them for anything.  So it's unsurprising that the
scalar VS backend didn't handle them quite right.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
This commit is contained in:
Kenneth Graunke 2015-09-09 20:23:04 -07:00
parent 511a86383b
commit 39d4b553a8
1 changed files with 2 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
View File

@ -939,9 +939,6 @@ fs_visitor::emit_urb_writes()
unreachable("unexpected scalar vs output");
break;
case BRW_VARYING_SLOT_PAD:
break;
default:
/* gl_Position is always in the vue map, but isn't always written by
* the shader. Other varyings (clip distances) get added to the vue
@ -951,7 +948,8 @@ fs_visitor::emit_urb_writes()
* slot for writing we flush a mlen 5 urb write, otherwise we just
* advance the urb_offset.
*/
if (this->outputs[varying].file == BAD_FILE) {
if (varying == BRW_VARYING_SLOT_PAD ||
this->outputs[varying].file == BAD_FILE) {
if (length > 0)
flush = true;
else