Nouveau - May 2020 - [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 3:10 PM Thomas Zimmermann <tzimmermann at suse.de>
wrote:
>
> Hi Alex
>
> Am 12.05.20 um 20:32 schrieb Alex Deucher:
> > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann <tzimmermann at
suse.de> wrote:
> >>
> >> Hi
> >>
> >> Am 11.05.20 um 19:17 schrieb Christian K?nig:
> >>> Hi guys,
> >>>
> >>> Well let's face it AGP is a total headache to maintain and
dead for at least 10+ years.
> >>>
> >>> We have a lot of x86 specific stuff in the architecture
independent graphics memory management to get the caching right, abusing the DMA
API on multiple occasions, need to distinct between AGP and driver specific page
tables etc etc...
> >>>
> >>> So the idea here is to just go ahead and remove the support
from Radeon and Nouveau and then drop the necessary code from TTM.
> >>>
> >>> For Radeon this means that we just switch over to the driver
specific page tables and everything should more or less continue to work.
> >>>
> >>> For Nouveau I'm not 100% sure, but from the code it of
hand looks like we can do it similar to Radeon.
> >>>
> >>> Please comment what you think about this.
> >>
> >> There's some AGP support code in the DRM core. Can some of
that declared
> >> as legacy?
> >>
> >> Specifically, what about these AGP-related ioctl calls? Can they
be
> >> declared as legacy? It would appear to me that KMS-based drivers
don't
> >> have to manage AGP by themselves. (?)
> >
> > The old drm core AGP code is mainly (only?) for the non-KMS drivers.
> > E.g., mach64, r128, sis, savage, etc.
>
> Exactly my point. There's one drm_agp_init() call left in radeon. The
> rest of the AGP code is apparently for legacy non-KMS drivers. Should
> the related ioctl calls be declared as legacy (i.e., listed with
> DRM_LEGACY_IOCTL_DEF instead of DRM_IOCTL_DEF)? If so, much of the AGP
> core code could probably be moved behind CONFIG_DRM_LEGACY as well.
Ah, I forgot about drm_agp_init().  I was just thinking the other AGP
stuff.  Yeah, I think we could make it legacy.

Alex

>
> Best regards
> Thomas
>
> >
> > Alex
> >
> >>
> >> Best regards
> >> Thomas
> >>
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> >>>
> >>> _______________________________________________
> >>> Nouveau mailing list
> >>> Nouveau at lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/nouveau
> >>>
> >>
> >> --
> >> Thomas Zimmermann
> >> Graphics Driver Developer
> >> SUSE Software Solutions Germany GmbH
> >> Maxfeldstr. 5, 90409 N?rnberg, Germany
> >> (HRB 36809, AG N?rnberg)
> >> Gesch?ftsf?hrer: Felix Imend?rffer
> >>
> >> _______________________________________________
> >> amd-gfx mailing list
> >> amd-gfx at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 N?rnberg, Germany
> (HRB 36809, AG N?rnberg)
> Gesch?ftsf?hrer: Felix Imend?rffer
>

On Tue, 12 May 2020 at 20:48, Alex Deucher <alexdeucher at gmail.com>
wrote:
> > >>
> > >> There's some AGP support code in the DRM core. Can some
of that declared
> > >> as legacy?
> > >>
> > >> Specifically, what about these AGP-related ioctl calls? Can
they be
> > >> declared as legacy? It would appear to me that KMS-based
drivers don't
> > >> have to manage AGP by themselves. (?)
> > >
> > > The old drm core AGP code is mainly (only?) for the non-KMS
drivers.
> > > E.g., mach64, r128, sis, savage, etc.
> >
> > Exactly my point. There's one drm_agp_init() call left in radeon.
The
> > rest of the AGP code is apparently for legacy non-KMS drivers. Should
> > the related ioctl calls be declared as legacy (i.e., listed with
> > DRM_LEGACY_IOCTL_DEF instead of DRM_IOCTL_DEF)? If so, much of the AGP
> > core code could probably be moved behind CONFIG_DRM_LEGACY as well.
>
> Ah, I forgot about drm_agp_init().  I was just thinking the other AGP
> stuff.  Yeah, I think we could make it legacy.
>
Fwiw I've got local patches a) removing drm_agp_init() from radeon and
b) making the core drm code legacy only.
Will try to finish them over the weekend and send out.

Even if AGP GART gets dropped the b) patches will be good ;-)

-Emil

Hi

Am 13.05.20 um 11:27 schrieb Emil Velikov:
> On Tue, 12 May 2020 at 20:48, Alex Deucher <alexdeucher at gmail.com>
wrote:
> 
>>>>>
>>>>> There's some AGP support code in the DRM core. Can some
of that declared
>>>>> as legacy?
>>>>>
>>>>> Specifically, what about these AGP-related ioctl calls? Can
they be
>>>>> declared as legacy? It would appear to me that KMS-based
drivers don't
>>>>> have to manage AGP by themselves. (?)
>>>>
>>>> The old drm core AGP code is mainly (only?) for the non-KMS
drivers.
>>>> E.g., mach64, r128, sis, savage, etc.
>>>
>>> Exactly my point. There's one drm_agp_init() call left in
radeon. The
>>> rest of the AGP code is apparently for legacy non-KMS drivers.
Should
>>> the related ioctl calls be declared as legacy (i.e., listed with
>>> DRM_LEGACY_IOCTL_DEF instead of DRM_IOCTL_DEF)? If so, much of the
AGP
>>> core code could probably be moved behind CONFIG_DRM_LEGACY as well.
>>
>> Ah, I forgot about drm_agp_init().  I was just thinking the other AGP
>> stuff.  Yeah, I think we could make it legacy.
>>
> Fwiw I've got local patches a) removing drm_agp_init() from radeon and
> b) making the core drm code legacy only.
> Will try to finish them over the weekend and send out.
> 
> Even if AGP GART gets dropped the b) patches will be good ;-)
Fantastic! Please see one of my other comments in this thread. There's
still drm_agp_init() somewhere in radeon_drv.c. So patch a) might still
be useful.

Best regards
Thomas
> 
> -Emil
> 
-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 N?rnberg, Germany
(HRB 36809, AG N?rnberg)
Gesch?ftsf?hrer: Felix Imend?rffer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20200513/ec007d51/attachment.sig>