Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • > New generation is so oversensitive: We were experimenting on Gen 11 hardware (RX 7900 XT) while Faith was working with a 10th Gen GPU (RX 7800 XT). We weren't able to replicate Faith's results for quite a while, due to architecture changes between these two generations.

    ... they are both RDNA3?

  • Impressive progress—getting CS2 running is a huge milestone. Hopefully AMD provides a stable KMD interface so this can become more than an exciting experiment.
  • Developing 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 than welcome to attempt --- is to port the existing open-source Linux drivers for AMD/NVIDIA/Intel to early Windows versions that never even had closed-source drivers available, giving them full 2D/3D acceleration. Theoretically, something as crazy as CUDA on Windows 95 is possible, and perhaps some vibecoding can turn that into reality. After all, as I write this comment, https://news.ycombinator.com/item?id=49089814 is on the main page.)

  • Certainly OpenGL and DirectX acceleration was a thing in Windows 9x, kind of missing the point.
  • 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.
  • 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).

  • For Windows 3x/9x the common term was VxD, KMD strongly implies an NT derived OS.
    by ZiiS
  • In order to have a useful Windows desktop, you need a DX12 driver.

    So, in order to write their own KMD, they'd either have to also write their own DX12 driver, which they probably have no interest in, or reverse engineer the existing AMD KMD interface to the point where they can reimplement it basically completely so that AMD's proprietary DX12 driver runs on it.

    I doubt they're saying it's impossible, it's more of a pick your battles situation.

  • 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.