Note that we do not need a KMS (kernel mode setting) part (which supposedly runs at bootloader stage to show a boot logo and that's it), only actual thing that enables GCN "engines" and whole functionality.

Notice: GCN aliased as "SI" (Southern Islands, Sea Islands) and GFX6 (gfx601), our point of interest is Oland CPU only for now.

Find out what is the difference between uppercase & lowercase firmware files, and radeon vs amdgpu ones:

• https://github.com/endlessm/linux-firmware/tree/master/amdgpu
• https://github.com/endlessm/linux-firmware/tree/master/radeon

DRM code is here linux\drivers\gpu\drm

Points of interest:

• amd\amdgpu\gfx_v6_0.c line MODULE_FIRMWARE("amdgpu/oland_pfp.bin"); (note amdgpu/ part)
• amd\amdgpu\amdgpu_cgs.c line trcpy(fw_name, "radeon/oland_k_smc.bin"); (note radeon/ part)
• radeon\si.c line MODULE_FIRMWARE("radeon/OLAND_smc.bin"); and lowercase MODULE_FIRMWARE("radeon/oland_smc.bin"); (note radeon/ part)

• [ ] Understand how https://github.com/pdoane/osdev/tree/master/gfx implementation works

Must be checked against Intel Ivy Bridge w/ HD Graphics 4000 spec (supposedly Gen 7, pre-DX12 GPU) PCI\VEN_8086\DEV_0162

• Intel OpenSource HD Graphics Programmer's Reference Manual (supposedly https://github.com/Igalia/intel-osrc-gfx-prm/tree/master/004_ivb_-_2012)

• Intel Integrated Graphics Device OpRegion Specification

• [ ] Understand how it differs from HD 500+ devices, by checking corresponding specs

What experience we can reuse? Command ring/buffer layout, memory allocation, DMA mapping, etc

Elaborate:

• [ ] Correct PCI IDs and generation aliases/common names/mesa|drm names for the provided GPUs
• [ ] Find correct firmware in linux-firmware

Devices:

• [ ] Intel HD Graphics 500 (Gen. 9 (Skylake))
• [ ] Intel UHD Graphics 630 (Gen. 9.5 (Kaby Lake))
• [ ] Intel UHD Graphics 750 (Gen. 12 (Rocket Lake-S))
• [ ] Iris Xe Graphics G7 (Gen. 12 (Tiger Lake-U))

PDF's must contain:

• [ ] List of GPU registers (at least, ones from Mesa code)
• [ ] List of packets for GPU engine
• [ ] Optionally: init routine, memory management, whatever

Code must contain:

• [ ] Linux DRM part related to the exact GPU generation linux\drivers\gpu\drm
• [ ] Mesa counterpart

Reference:

• AMD https://llvm.org/docs/AMDGPUUsage.html
• Intel https://github.com/pdoane/osdev/blob/master/gfx/shaders/make_shaders.sh#L2

Goals:

• [ ] Generate shader binary to be uploaded into GPU for quick testing. Not SPIR-V/etc. It must be CPU/model specific.

• [ ] Check if its possible to decompile shader / output ASM with -S flag.

• [ ] Find shader decompilers, so we can decompile shaders binaries generated by the NjRAA for verification

• Oland (GCN 1)

• Intel 630/750 of @Samsuper12's

Note: only raw PCI driver required, not DRI/DRM.

It must also create some APIs to be controlled from users pace.

It must use WDF-like framework for PNP, so we don't have to implement power management manually.

Reference:

• https://www.kernel.org/doc/html/latest/PCI/pci.html
• http://www.embeddedlinux.org.cn/essentiallinuxdevicedrivers/final/ch10lev1sec5.html
• https://olegkutkov.me/2021/01/07/writing-a-pci-device-driver-for-linux/
• https://habr.com/ru/post/348042/
• https://habr.com/ru/post/431372/
• https://qna.habr.com/q/229124

https://www.codeproject.com/Articles/13090/Building-and-deploying-a-basic-WDF-Kernel-Mode-Dri

For those of you who don't know what WDF is: it is the best invention since sliced bread. Until recently, if you needed a device driver, you had to use the Windows Driver Model (WDM). WDM provides a low level framework for creating device drivers. Using this framework, your driver had to accept PNP, Power management, and IO requests, and figure out what to do with them, based on the state of your driver.