[Mesa-dev] i965 driver questions

[Paul Berry]

On 9 October 2013 03:33, Rogovin, Kevin <kevin.rogovin at intel.com> wrote:

> Hi all,
>
>  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:
>
>   *   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.
>

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".


>   *   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?
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131018/57fb0af0/attachment-0001.html>