<div dir="ltr">On 9 October 2013 03:33, Rogovin, Kevin <span dir="ltr"><<a href="mailto:kevin.rogovin@intel.com" target="_blank">kevin.rogovin@intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
 I've been digging through the i965 driver implementation attempting to get my head around it. I have a few questions which I hope can be answered:<br>
<br>
  *   What is LIR? The comments say that Mesa GLSL IR is converted into LIR which in turn is converted into GPU code. What is LIR and how is the LIR represented? I am guessing LIR is some intermediate thing used by i965 before going to code for different GPUs supported on the i965 or "Lower IR" from Mesa upstairs.<br>
</blockquote><div><br></div><div>We haven't really used the terminology "LIR" very consistently.  Theres is a lower-level intermediate representation we use in the i965 back-end which is pretty close to assembly instructions (see the vec4_instruction and fs_inst classes), but the only terminology I've heard us consistently apply to these representations is "backend instructions".<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  *   In brw_misc_state.c, why does brw_workaround_depthstencil_alignment() even exist? I understand the work around issue, but why are not those buffers allocated so that they are aligned? Moreover, I did not really understand the remark for Gen7 hardware:  "Gen7+ doesn't require the workarounds, since we always program the surface state at the start of the whole surface." not needing the workaround, is that comment talking about a specific brw_state_tracker in gen7_atoms (of brw_state_upload) or about how the memory is allocated or something else?<br>
</blockquote><div><br></div><div>The issue is that due to a quirk of how we've implemented rendering on pre-gen7, there are different layout requirements for texturing and rendering.  When texturing, the different miplevels and array slices are required to be laid out in a precise arrangement on the texture size.  The hardware also supports rendering to this arrangement, however for historical reasons, we don't take care of that capability until gen7.  For pre-gen7 hardware, we instead lie to the hardware and tell it that it's always rendering to level 0 and layer 0, and we adjust the buffer's base address and X/Y offsets to cause rendering to go to the right location.  However, that lie sometimes doesn't work because of alignment restrictions.  When that happens, we render to temporary buffers that are properly aligned, and later copy the rendered data into the correct arrangement.  The job of brw_workaround_depthstencil_alignment is to figure out if the lie is going to work.  If so, it computes the necessary buffer address offset and X/Y offsets to accomplish the lie.  If not, it creates the temporary buffers.<br>
<br></div><div>Earlier this year, we added the code to gen7 to avoid lying to the hardware about rendering level and layer--this allowed us to drop brw_workaround_depthstencil_alignment() for that platform (it was a necessary prerequisite for implementing geometry shaders).  In an ideal world, we'd backport that code to pre-gen7 and drop brw_workaround_depthstencil_alignment entirely.  But we haven't had the time to do that.<br>
</div></div></div></div>