[Mesa-dev] [PATCH 00/10] i965: Add a width field to fs_inst
Jason Ekstrand
jason at jlekstrand.net
Fri Sep 5 09:32:46 PDT 2014
On Thu, Sep 4, 2014 at 11:03 PM, Matt Turner <mattst88 at gmail.com> wrote:
> On Thu, Sep 4, 2014 at 10:19 PM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
> > This is the first chunk of patches in my work on adding instruction and
> > register widths to the fs backend. Eventually, this will allow us to
> more
> > easily emit 8-wide instructions in SIMD16 mode from the fs_visitor level.
> > More patches will be coming to add a width field to the registers and
> allow
> > for more fine-grained register allocation.
>
> I think we're using the wrong terminology here. Instructions don't
> have widths; registers do. Instructions have execution sizes (and so
> you should use the BRW_EXECUTE_* macros).
>
Sure, I can call it execution size instead of width. I don't really care
if we use the integer value (as we do for dispatch width) or the macro
enumeration.
I guess I'm having a hard time seeing the whole picture, i.e., what
> explicit instruction execsizes buys us. Is there a branch with work
> that builds on this that I should look at?
>
Ok, I'm in the process of trying to put some pieces together. I'll let you
know when I've got a bigger picture branch for you to poke at. I'm fine if
it rots on the list until then.
What's the point? The short answer is that it makes things more explicit.
Sure, we can get all this information from fs_visitor::dispatch_width,
fs_inst::force_uncompressed, and fs_inst::force_sechalf, but this makes the
execution size an explicit concept. Also, for 32-wide dispatch (which we
will need for compute shaders), the current collection of boolean flags
won't work. I would like to replace force_sechalf with an execution offset
that's either 0 or 1 in 16-wide and 0, 1, 2, or 3 in 32-wide.
Thanks,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140905/984fb31e/attachment.html>
More information about the mesa-dev
mailing list