----- Mail original -----
> De: "Rodrigo Siqueira Jordao" <[email protected]>
> À: [email protected], "Rodrigo Siqueira" <[email protected]>, "Christian
> König" <[email protected]>,
> "Alex Deucher" <[email protected]>
> Cc: "Harry Wentland" <[email protected]>, "Linux Doc Mailing List"
> <[email protected]>, "Mark Yacoub"
> <[email protected]>, "Michel Dänzer" <[email protected]>, "Bas
> Nieuwenhuizen" <[email protected]>,
> "Roman Li" <[email protected]>, "amd-gfx list"
> <[email protected]>, "Roman Gilg" <[email protected]>,
> "Marek Olšák" <[email protected]>, "Pekka Paalanen" <[email protected]>,
> "Aurabindo Pillai"
> <[email protected]>, "nicholas choi" <[email protected]>, "Maling
> list - DRI developers"
> <[email protected]>, "Simon Ser" <[email protected]>, "Alex
> Deucher" <[email protected]>, "Sean
> Paul" <[email protected]>, "Qingqing Zhuo" <[email protected]>,
> "Bhawanpreet Lakha"
> <[email protected]>, "Nicholas Kazlauskas"
> <[email protected]>
> Envoyé: Mardi 30 Novembre 2021 16:53:55
> Objet: Re: [PATCH 6/6] Documentation/gpu: Add DC glossary
>
>
>
> On 2021-11-29 3:48 p.m., [email protected] wrote:
> > Hi Rodrigo,
> >
> > That will really be helpful!
> >
> > I know drawing the line is a difficult problem (and can even make
> > things
> > harder when searching), but maybe it would make sense to keep
> > generic
> > acronyms not specific to amdgpu in a separate list. I bet a number
> > of
> > them would be useful in the scope of other drm drivers (e.g. CRTC,
> > DCC,
> > MST), and some are not restricted to the drm subsystem at all (e.g.
> > FEC,
> > LUT), but still have value as not necessarily easy to look up.
> >
> > Maybe "DC glossary" should just be "Glossary", since quite some
> > entries
> > help to read adm/amdgpu/ too. Which brings me to the result of my
> > recent
> > searches as suggested entries:
> >
> > KIQ (Kernel Interface Queue), MQD (memory queue descriptor), HQD
> > (hardware
> > queue descriptor), EOP (still no clue :)
> >
> > Maybe some more specific ones just to be spelled out in clear where
> > they
> > are used ? KCQ (compute queue?), KGQ (gfx queue?)
> >
> > More suggestions inlined.
> >
> > Best regards,
> >
>
> Hi all,
>
> I'll address all the highlighted problems in the V2. Thanks a lot for
> all the feedback.
>
> Yann,
> For the generic acronyms, how about keeping it in this patch for now?
> After it gets merged, I can prepare a new documentation patch that
> creates a glossary for DRM where I move the generic acronyms to the
> DRM
> documentation. I prefer this approach to keep the improvement small
> and
> manageable.
Sure, especially as the Right Solution(tm) is not necessarily obvious :)
One thing I thought about is that a context could be specified together
with terms. Like "BPP (graphics)", "FEC (CS)", "DMCUB (amdgpu)". Well,
"CS" may not be a good choice but you get the idea: that would keep all
terms together and keep it easy for the reader.
That way it could be easily be generalized at some point by just moving
it to a generic kernel level - provided the solution suits the doc
community at large.
Best regards,
--
Yann