Linux 5.9-rc1 Kernel Released - Line Count Dominated By AMD Radeon Navi 2 Additions

[pal666]

Intuitively I always think that if it can be autogenerated it could also be replaced by smart code that does the same thing in a more on-the-fly manner or dinamically on compile time?

they are autogenerated from large and non-open data(hardware).

[kripteks]

My vega cant overclock with this 5.9-rc1, same issue with all linux-next after 5.8.0.


In same time, i have also this:
# dmesg | grep dax
[ 2.912377] sda1: error: dax access failed (-95)
[ 2.913027] sda1: error: dax access failed (-95)
[ 2.913682] sda1: error: dax access failed (-95)
[ 2.914431] sda1: error: dax access failed (-95)
[ 2.915016] sda1: error: dax access failed (-95)
[ 2.915596] sda1: error: dax access failed (-95)

Sometimes my disk dont respond few second when i write text file with geany.

[nivedita]

One thing I don't quite understand is the need for so many of those autogenerated lines of code.

Intuitively I always think that if it can be autogenerated it could also be replaced by smart code that does the same thing in a more on-the-fly manner or dinamically on compile time?

Obviously this is a non-expert view and there must be a ton of perfectly reasonable motives for it, I'm just curious to how that goes and haven't bumped into a for-noobs version of the explanation yet.

Is this initially auto-generated then gradually tweaked, is there a limitation in the programming language in this case because it's about headers, would it kill performance if done on the fly, is it impossible to autogenerate on compile time?

I don't know about this case, but one consideration in general is what tools are required to generate it, since those are unlikely to be commonly installed. The choice is to either include the auto-generated output in the kernel tree, or you need to include the input, and also either put the tools in the kernel tree (increasing build time since you have to build the tools first) or require anyone who wants to compile that driver to download and install the tools.

[bridgman]

If you don't mind, here's what I've always wondered... Why would a chip have significantly more registers than a (feature-complete) driver ends up using?

Does it mean that the driver does not make full use of available hardware features, or is otherwise limited in some regards? Or does it instead mean that the hardware is being designed with a vast array of mutually redundant/overlapping usecases in mind, some of which are never realized at all?

Two part answer:

#1 - in the early days of the open source graphics effort the drivers were not anywhere near feature complete

#2 - as mlau pointed out, a number of registers are there for debug and other troubleshooting activities - those may be set by the driver (golden settings) or by firmware

There are relatively few registers that are not used by some part of the FW/SW stack.

We could make the register headers a bit smaller by making a guess about which registers we would never want to access from the driver, but that gets us back into having to do incremental IP reviews every time we use a new register.

[mlau]

If you don't mind, here's what I've always wondered... Why would a chip have significantly more registers than a (feature-complete) driver ends up using?

Does it mean that the driver does not make full use of available hardware features, or is otherwise limited in some regards? Or does it instead mean that the hardware is being designed with a vast array of mutually redundant/overlapping usecases in mind, some of which are never realized at all?

Various bits to disable/bypass functions, test bits, status bits for silicon testing, ...

[intelfx]

The files are big because the chips have a lot of registers. We used to only IP review and release register info for the registers we were actually using (since IP review was so painful in the early days of the open source effort) but now IP review and release info for essentially all of the registers from the start, so that if the driver code needs to access a new register we don't have to go through another round of IP review. It does make the files bigger though.

If you don't mind, here's what I've always wondered... Why would a chip have significantly more registers than a (feature-complete) driver ends up using?

Does it mean that the driver does not make full use of available hardware features, or is otherwise limited in some regards? Or does it instead mean that the hardware is being designed with a vast array of mutually redundant/overlapping usecases in mind, some of which are never realized at all?

[bridgman]

I don't think we have any auto-generated code in the driver other than register definition headers. What they contain is:

- for each register in the GPU, register name and offset from start of register BAR (xxx_offset.h)
- for each field in each register, shift and mask values to access that field (xxx_sh_mask.h)

The files are big because the chips have a lot of registers. We used to only IP review and release register info for the registers we were actually using (since IP review was so painful in the early days of the open source effort) but now IP review and release info for essentially all of the registers from the start, so that if the driver code needs to access a new register we don't have to go through another round of IP review. It does make the files bigger though.

Register header files are provided for each version of an IP block, but if different chips use the same IP block version we also re-use the header files, so as an example NAVY_FLOUNDER added only a couple of hundred lines of header file info. Organizing the driver code around IP blocks and block versions was one of the big changes going from radeon to amdgpu.

The files are in drivers/gpu/drm/amd/include/asic_reg if you want to take a look.

The main remaining inefficiency that would be nice to eliminate is that in cases where we have multiple instances of the same block (I think this only applies to SDMA) we also have multiple instances of the header files. The files aren't that big though...

[JustRob]

One thing I don't quite understand is the need for so many of those autogenerated lines of code.

Intuitively I always think that if it can be autogenerated it could also be replaced by smart code ... is it impossible to autogenerate on compile time?

It is generated before compilation, by running ./configure - that then assesses which OS, Compiler version, libraries, many, many, things, you are using and does the magic necessary for the code base to work with the largest number of different setups. A small amount of source code can remain unchanged and configuring can substitute OS and Library differences permitting different systems with adequate overlap in their capabilities to run the same code (often with a difference in the feature set).

There's not really a 'noob explanation', but here's the Docs: https://www.gnu.org/software/autogen...l#Generalities

[acobar]

NFS extended attribute protocol patches were merged on Linus branch, fingers crossed !

https://lkml.org/lkml/2020/8/15/44

Looks like 5.9 kernel will be a really good version.

[marlock]

I was imagining something a little more like boilerplate code, but that makes a lot more sense! Thanks!