Alexandre Courbot
2025-Nov-19 02:45 UTC
[PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification
On Wed Nov 19, 2025 at 10:46 AM JST, John Hubbard wrote:> On 11/6/25 2:24 PM, John Hubbard wrote: >> On 11/6/25 6:44 AM, Timur Tabi wrote: >>> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote: >>>> ???? let hal = match chipset { >>>> -??????? GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107 >>>> => { >>>> +??????? GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107 >>>> +??????? | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => { >>>> ???????????? KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>> >>>> ???????? } >>> >>> Maybe combine patches 2 and 3? Also, maybe this should be a range check, instead of listing >>> every since version? It seems like everything past GA100 uses the GA102 HAL. >>> >> >> Sure, I can combine the patches. >> >> I'm not sure why I've been wary of using ranges for these arch's. >> I'll try it out. > > Now I know. :) Unlike C, Rust does *not* like it when we try to > treat enums as integers. Casting or other (messier) approaches are > required, and in no case is the end result a more readable on-screen > experience. At least not so far. > > It is possible to mix in Architecture (Turing, Ampere, etc) checks, > but I'm not sure that is worth the additional clutter. > > Maybe let's just do the long lists of chipsets for now...?Yeah, I've hit this issue as well. The compiler might remove that limitation in the future, or maybe we can craft a `chipset_range!()` macro that hides the messy casting, but this exhaustive listing also has the benefit of forcing us to consider every critical site whenever we support a new chipset so I'm actually not too bothered by it.
Dave Airlie
2025-Nov-19 03:15 UTC
[PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification
On Wed, 19 Nov 2025 at 12:46, Alexandre Courbot <acourbot at nvidia.com> wrote:> > On Wed Nov 19, 2025 at 10:46 AM JST, John Hubbard wrote: > > On 11/6/25 2:24 PM, John Hubbard wrote: > >> On 11/6/25 6:44 AM, Timur Tabi wrote: > >>> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote: > >>>> let hal = match chipset { > >>>> - GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107 > >>>> => { > >>>> + GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107 > >>>> + | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => { > >>>> KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>> > >>>> } > >>> > >>> Maybe combine patches 2 and 3? Also, maybe this should be a range check, instead of listing > >>> every since version? It seems like everything past GA100 uses the GA102 HAL. > >>> > >> > >> Sure, I can combine the patches. > >> > >> I'm not sure why I've been wary of using ranges for these arch's. > >> I'll try it out. > > > > Now I know. :) Unlike C, Rust does *not* like it when we try to > > treat enums as integers. Casting or other (messier) approaches are > > required, and in no case is the end result a more readable on-screen > > experience. At least not so far. > > > > It is possible to mix in Architecture (Turing, Ampere, etc) checks, > > but I'm not sure that is worth the additional clutter. > > > > Maybe let's just do the long lists of chipsets for now...? > > Yeah, I've hit this issue as well. The compiler might remove that > limitation in the future, or maybe we can craft a `chipset_range!()` > macro that hides the messy casting, but this exhaustive listing also has > the benefit of forcing us to consider every critical site whenever we > support a new chipset so I'm actually not too bothered by it.I wrote some macros in my nova-core-experiments, had chipset_before/after/range I think Dave.