On Thu, Sep 4, 2014 at 11:03 PM, Matt Turner <matts...@gmail.com> wrote:
> On Thu, Sep 4, 2014 at 10:19 PM, Jason Ekstrand <ja...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
