drmVersion::name = amdgpu, radeon, intel, etc. drmVersion::desc = vega10, vega12, vega20, ...
The common Mesa code will use name and desc to select the driver. The AMD-specific Mesa code will use desc to identify the chip. Mesa won't receive any PCI IDs for future chips. Marek On Tue, Sep 17, 2019 at 10:33 AM Michel Dänzer <mic...@daenzer.net> wrote: > On 2019-09-17 1:20 p.m., Christian König wrote: > > Am 17.09.19 um 11:27 schrieb Michel Dänzer: > >> On 2019-09-17 11:23 a.m., Michel Dänzer wrote: > >>> On 2019-09-17 10:23 a.m., Koenig, Christian wrote: > >>>> Am 17.09.19 um 10:17 schrieb Daniel Vetter: > >>>>> On Tue, Sep 17, 2019 at 10:12 AM Christian König > >>>>> <ckoenig.leichtzumer...@gmail.com> wrote: > >>>>>> Am 17.09.19 um 07:47 schrieb Jani Nikula: > >>>>>>> On Mon, 16 Sep 2019, Marek Olšák <mar...@gmail.com> wrote: > >>>>>>>> The purpose is to get rid of all PCI ID tables for all drivers in > >>>>>>>> userspace. (or at least stop updating them) > >>>>>>>> > >>>>>>>> Mesa common code and modesetting will use this. > >>>>>>> I'd think this would warrant a high level description of what you > >>>>>>> want > >>>>>>> to achieve in the commit message. > >>>>>> And maybe explicitly call it uapi_name or even uapi_driver_name. > >>>>> If it's uapi_name, then why do we need a new one for every > generation? > >>>>> Userspace drivers tend to span a lot more than just 1 generation. And > >>>>> if you want to have per-generation data from the kernel to userspace, > >>>>> then imo that's much better suited in some amdgpu ioctl, instead of > >>>>> trying to encode that into the driver name. > >>>> Well we already have an IOCTL for that, but I thought the intention > >>>> here > >>>> was to get rid of the PCI-ID tables in userspace to figure out which > >>>> driver to load. > >>> That's just unrealistic in general, I'm afraid. See e.g. the ongoing > >>> transition from i965 to iris for recent Intel hardware. How is the > >>> kernel supposed to know which driver is to be used? > > > > Well how is userspace currently handling that? The kernel should NOT say > > which driver to use in userspace, but rather which one is used in the > > kernel. > > Would that really help though? E.g. the radeon kernel driver supports > radeon/r200/r300/r600/radeonsi DRI drivers, the i915 one i915/i965/iris > (and the amdgpu one radeonsi/amdgpu). > > The HW generation identifier proposed in these patches might be useful, > but I suspect there'll always be cases where userspace needs to know > more precisely. > > > > Mapping that information to an userspace driver still needs to be done > > somewhere else, but the difference is that you don't need to add all > > PCI-IDs twice. > > It should only really be necessary in Mesa. > > > On 2019-09-17 1:32 p.m., Daniel Vetter wrote: > > How are other compositors solving this? I don't expect they have a > > pciid table like modesetting copied to all of them ... > > They don't need any of this. The Xorg modesetting driver only did for > determining the client driver name to advertise via the DRI2 extension. > > > -- > Earthling Michel Dänzer | https://redhat.com > Libre software enthusiast | Mesa and X developer > _______________________________________________ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx