Re: [PATCH v10 03/28] gpu: nova-core: Hopper/Blackwell: basic GPU identification

[John Hubbard]

On 4/13/26 2:21 PM, Timur Tabi wrote:
> On Mon, 2026-04-13 at 14:08 -0700, John Hubbard wrote:
>>> Can you add something to the patch description that explains why Blackwell, unlike all of the
>>> olther architectures, is represented by two Architecture enums?
>>
>> How's this:
>>
>> Blackwell uses two Architecture variants because the hardware itself
>> exposes two distinct architecture IDs in NV_PMC_BOOT_0: 0x1A for

This is really what drove it, for me, though: the hardware itself
saw fit to identify these two variants as architectures. It's
encoded into the very fabric of space-time itself! haha :)

>> GB10x (GB100, GB102) and 0x1B for GB20x (GB202, GB203, GB205, GB206,
>> GB207). Open RM maps these into separate chip families with distinct
>> HAL routing and different firmware signature sections.
> 
> We don't need two arch's for Ampere to handle different firmware signature sections.  Looking
> through your patches, the vast majority do this:
> 
> 	Architecture::BlackwellGB10x | Architecture::BlackwellGB20x
> 
> Looking through your patches, it seems overkill to separate these two.  The one or two instances
> where it makes a difference, an if-statement will suffice.

It's arguably worse, however, to save a (very) few lines of code, in
favor of adding special cases into the basic Arch/chipset categorization.

Again, it would be one thing if this were a software decision. But the
HW itself set this up. So it's reasonable to follow the HW.

> 
> As for OpenRM, IMHO RM is very much HAL-happy.  There's a whole built-in mechanism for hal-ifying
> any function at any chip level.  Nova isn't really like that.

This is not something that Open RM did. It's something that HW did.
And so while Open RM criticisms about HAL granularity are reasonable,
they do not apply here.

> 
> Anyway, I don't want to belabor this point.  It just seems to me that since you have "GB10x | GB20x"
> more more frequently than you don't, I don't think this warrants two architecture enums.
> 

thanks,
-- 
John Hubbard