[deleted]
Cracking Windows Open: Porting RADV to Win32
11–20 of 29 posts
Re: Cracking Windows Open: Porting RADV to Win32
#12Developing our own KMD is not really an option Why not? Fully open-source Windows GPU drivers would be great. Incidentally, this sort of "glue code" is probably something LLM assistance could help greatly with much of the grunt work. (E.g. there is already a generic framebuffer driver for Win3x/9x: https://news.ycombinator.com/item?id=47646363 but one of the ideas I have --- which anyone else with the time is more th…
You can't really develop a kernel-mode driver nowadays without being an incredibly large OEM. Otherwise, you won't be accepted by any anti-cheat.
So we should throw away the possibility entirely just because of a few videogames? That doesn't sound reasonable at all, considering most videogames don't have anti cheats and GPUs can be used for way more stuff than playing.
Re: Cracking Windows Open: Porting RADV to Win32
#13Developing our own KMD is not really an option Why not? Fully open-source Windows GPU drivers would be great. Incidentally, this sort of "glue code" is probably something LLM assistance could help greatly with much of the grunt work. (E.g. there is already a generic framebuffer driver for Win3x/9x: https://news.ycombinator.com/item?id=47646363 but one of the ideas I have --- which anyone else with the time is more th…
I almost wrote the same comment — the first part, anyways.
In theory, it should be feasible to provide a "shim" to bridge the API gap between Linux and Windows internal APIs. The catch here is that Linux is a moving target.
AMDGPU (the Linux kernel module) has its roots in a shared Linux/Windows codebase from AMD, so hopefully it didn't get _too_ tightly integrated (I know some parts got integrated, IIRC it used to ship its own i2c driver).
Re: Cracking Windows Open: Porting RADV to Win32
#14Developing our own KMD is not really an option Why not? Fully open-source Windows GPU drivers would be great. Incidentally, this sort of "glue code" is probably something LLM assistance could help greatly with much of the grunt work. (E.g. there is already a generic framebuffer driver for Win3x/9x: https://news.ycombinator.com/item?id=47646363 but one of the ideas I have --- which anyone else with the time is more th…
You can't really develop a kernel-mode driver nowadays without being an incredibly large OEM. Otherwise, you won't be accepted by any anti-cheat.
If anti-cheats actively whitelisted drivers playing competitive video games would be impossible for people using any rarer HW/utilities. Vulnerable drivers are generally blacklisted when found.
Getting your driver signed seems like a pain these days, yeah
Re: Cracking Windows Open: Porting RADV to Win32
#15Earlier quoted context omitted.
You can't really develop a kernel-mode driver nowadays without being an incredibly large OEM. Otherwise, you won't be accepted by any anti-cheat.
If anti-cheats actively whitelisted drivers playing competitive video games would be impossible for people using any rarer HW/utilities. Vulnerable drivers are generally blacklisted when found. Getting your driver signed seems like a pain these days, yeah
I'm inclined to believe this is exactly what happens, given that both Bluetooth and my printer stopped working the last time I tried playing a Riot game.
Also got a BSOD in vgk.sys, and it left a bunch of junk in my EFI partition after I uninstalled it. Fun times.
Re: Cracking Windows Open: Porting RADV to Win32
#16Developing our own KMD is not really an option Why not? Fully open-source Windows GPU drivers would be great. Incidentally, this sort of "glue code" is probably something LLM assistance could help greatly with much of the grunt work. (E.g. there is already a generic framebuffer driver for Win3x/9x: https://news.ycombinator.com/item?id=47646363 but one of the ideas I have --- which anyone else with the time is more th…
Certainly OpenGL and DirectX acceleration was a thing in Windows 9x, kind of missing the point.
Videocards of the era only did exclusive fullscreen - you could not for example use OpenGL to render your windowed application's UI, that was all software.
Re: Cracking Windows Open: Porting RADV to Win32
#17Earlier quoted context omitted.
You can't really develop a kernel-mode driver nowadays without being an incredibly large OEM. Otherwise, you won't be accepted by any anti-cheat.
Wireguard...
Sandboxie/WinFSP/KVM guest drivers for Windows are open source too
I’m sure there are more open source examples. A newer one is https://github.com/namazso/PawnIO/tree/master I guess?
Re: Cracking Windows Open: Porting RADV to Win32
#18Earlier quoted context omitted.
You can't really develop a kernel-mode driver nowadays without being an incredibly large OEM. Otherwise, you won't be accepted by any anti-cheat.
If anti-cheats actively whitelisted drivers playing competitive video games would be impossible for people using any rarer HW/utilities. Vulnerable drivers are generally blacklisted when found. Getting your driver signed seems like a pain these days, yeah
Maybe drivers are treated differently, but I remember having to update Windows 11 to play ARC Raiders because my specific version was old enough that system files did not pass their whitelist check. It told me which system file failed the check - I don't remember which it was exactly, but it definitely wasn't one that'd ever been modified, just one that wasn't recent enough it seems, at least going off of how updating fixed it.
Re: Cracking Windows Open: Porting RADV to Win32
#19Earlier quoted context omitted.
Certainly OpenGL and DirectX acceleration was a thing in Windows 9x, kind of missing the point.
Videocards of the era only did exclusive fullscreen - you could not for example use OpenGL to render your windowed application's UI, that was all software.
My graduation thesis was porting a particle visualisation engine from NeXTSTEP into Windows 9x.
Re: Cracking Windows Open: Porting RADV to Win32
#20Developing our own KMD is not really an option Why not? Fully open-source Windows GPU drivers would be great. Incidentally, this sort of "glue code" is probably something LLM assistance could help greatly with much of the grunt work. (E.g. there is already a generic framebuffer driver for Win3x/9x: https://news.ycombinator.com/item?id=47646363 but one of the ideas I have --- which anyone else with the time is more th…
I am quite sure AMD is already using a fork of the Linux amdgpu KMD for their proprietary driver on Windows (which in part explains why a project like this can even be done)
Porting Linux drivers to anywhere is generally hard. It either makes your kernel very Linux-like (and lots of manpower to translate the abstractions), or forces you to put Linux on it. There are bazillions of projects to put recent Intel drivers on 9x and none suceeded, for example.
Plus my recent observation that for Haiku it was easier to port the out-of-tree nvidia driver and fork Mesa, than it was to port the Linux amdgpu one.