On Thu, Feb 22, 2018 at 02:31:48PM +0100, Erik Faye-Lund wrote:
> On Thu, Feb 22, 2018 at 2:23 PM, Thierry Reding
> <thierry.red...@gmail.com> wrote:
> > On Wed, Feb 21, 2018 at 05:01:02PM +0000, Emil Velikov wrote:
> >> Hi Thierry,
> >>
> >> On 21 February 2018 at 15:30, Thierry Reding <thierry.red...@gmail.com>
> >> wrote:
> >> > +static const char *
> >> > +tegra_screen_get_name(struct pipe_screen *pscreen)
> >> > +{
> >> > + return "tegra";
> >> > +}
> >> > +
> >> > +static const char *
> >> > +tegra_screen_get_vendor(struct pipe_screen *pscreen)
> >> > +{
> >> > + return "NVIDIA";
> >> > +}
> >> > +
> >> > +static const char *
> >> > +tegra_screen_get_device_vendor(struct pipe_screen *pscreen)
> >> > +{
> >> > + return "NVIDIA";
> >> > +}
> >> > +
> >> As-is these might be a bit fiddly, but will do for now.
> >> For example - how will devs distinguish between the closed-source
> >> driver and Mesa.
> >
> > Good point. Let me check what exactly we use in the closed-source driver
> > and then come up with a proposal.
> >
> > I think perhaps a good choice for the vendor would be "grate". Even
> > though this driver isn't part of the grate project, I'm hoping that we
> > will eventually see Erik's and Dmitry's work merged into this.
> >
> > Adding Erik and Dmitry to get their opinion.
> >
>
> It's not entirely clear to me what the most natural boundary between
> Tegra 2/3/4 (the GPUs the grate-project targets) and Tegra K1 would
> be. The later Tegras are so fundamentally different in how they
> work...
>
> Should they share the implementation of tegra_screen_create? From a
> quick look, it doesn't seem like it (mostly K1 specifics going on
> there, it seems), but I could be wrong. And if it shouldn't perhaps it
> should simply be a separate gallium-driver ("grate" vs "tegra"
> maybe?)... We can probably share some code, but we can do that without
> sharing the driver, just like intel, amd and broadcom does with just a
> shared folder at src/nvidia or something for utilities...
>
> I don't know, just trying to avoid having to add too many conditionals here...I agree with you mostly. I don't think there's a lot that could be shared here. On the other hand, I think we can easily add the conditionals to only a few places. We could for example have a grate_screen_create() function that is called by tegra_screen_create() after detecting whether or not we have a Nouveau GPU in the system (as fallback for a tegra_open_render_node() failure). Or we could do it earlier after checking for Tegra chip ID in sysfs, or perhaps some DT compatible string (via the drmDevice API). That way there is one conditional in the initial stages, but we get to deal with less fragmentation. I think it gives users a better experience if they just install the Tegra driver and it works regardless of whether it runs on a Tegra20 or a Tegra124. We have a pretty consistent experience across all Tegra generations, and I'd really like to keep that. All of that said, I'm not exactly sure I understand the purpose of the vendor name here. We already have the screen name that identifies this as a Tegra screen and we have the device vendor which identifies who built the device. So vendor seems to me like it would be whoever provides the driver. In this case, couldn't that just be "Mesa"? Thierry
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
