[Mesa-dev] [PATCH 5/5] tegra: Initial support

Erik Faye-Lund kusmabite at gmail.com
Thu Feb 22 13:31:48 UTC 2018


On Thu, Feb 22, 2018 at 2:23 PM, Thierry Reding
<thierry.reding at 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.reding at 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...


More information about the mesa-dev mailing list