On Tue, 2016-09-20 at 16:48 -0700, Kenneth Graunke wrote:
> On Friday, September 9, 2016 11:45:07 AM PDT Lionel Landwerlin wrote:
> [snip]
> > 
> > diff --git a/src/intel/vulkan/anv_private.h
> > b/src/intel/vulkan/anv_private.h
> > index 99b3acf..aa9be69 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -569,6 +569,20 @@ struct anv_physical_device {
> >      struct isl_device                           isl_dev;
> >      int                                         cmd_parser_version
> > ;
> >  
> > +    uint32_t                                    eu_total;
> > +    uint32_t                                    subslice_total;
> > +
> > +    /**
> > +     * Platform specific constants containing the maximum number
> > of threads
> > +     * for each pipeline stage.
> > +     */
> > +    uint32_t                                    max_vs_threads;
> > +    uint32_t                                    max_hs_threads;
> > +    uint32_t                                    max_ds_threads;
> > +    uint32_t                                    max_gs_threads;
> > +    uint32_t                                    max_wm_threads;
> > +    uint32_t                                    max_cs_threads;
> > +
> 
> One idea we've had for a while is to make a gen_device_info struct
> which is mutable, and initialize it from the static const ones we
> currently have.  But, then mutate the max_*_threads and other fields.

Thanks. Thought the same, but figured there was a reason for not doing
that.
I'll give it a try.

> 
> In GL, we've got a couple bugs on Cherryview currently because we
> have two copies of it, and some places use brw->* (the updated copy)
> and others use devinfo->* (the static const copy)...and they're not
> the same.  Just mutating gen_device_info would fix this, by having
> only one copy for everybody.
> 
> Anyway, I think we could do that as a later cleanup if you like.
> 
> Thanks for fixing this!  As is, these three are:
> Reviewed-by: Kenneth Graunke <kenn...@whitecape.org>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to