Hacker News new | ask | show | jobs
by an1sotropy 599 days ago
Sorry, I'll try to be clearer. QRhi docs[1] say "The Qt Rendering Hardware Interface is an abstraction for hardware accelerated graphics APIs, such as, OpenGL, OpenGL ES, Direct3D, Metal, and Vulkan." And PySide6 includes a (python) wrapper for QRhi[2]. Meanwhile, pygfx builds on wgpu-py[3] which builds on wgpu[4] which is a "is a cross-platform, safe, pure-rust graphics API. It runs natively on Vulkan, Metal, D3D12, and OpenGL".

So, from the standpoint of someone using PySide6, QRhi and pygfx seem to be alternative paths to doing GPU-enabled rendering, on the exact same range of GPU APIs.

Thus my question: How do they compare? How should I make an informed comparison between them?

[1] https://doc.qt.io/qt-6/qrhi.html

[2] https://doc.qt.io/qtforpython-6/PySide6/QtWidgets/QRhiWidget...

[3] https://github.com/pygfx/wgpu-py/

[4] https://github.com/gfx-rs/wgpu
2 comments
Calavar 599 days ago
> How should I make an informed comparison between them?

Pygfx provides higher level rendering primitives. The more apples to apples comparison would be wgpu-py versus QtRhi, both of which are middleware that abstract the underlying graphics API.

The natural question is are you already using Qt? You say you are, so IMHO the pros and cons of the specific implementations don't matter unless you have some very specific exotic requirements. Stick with the solution that "just works" in the existing ecosystem and you can jump into implementing your specific business logic right away. The other option is getting lost in the weeds writing glue code to blit a wgpu-py render surface into your Qt GUI and debugging that code across multiple different render backends.

link
almarklein 599 days ago
Yeah, sounds like QRhi is about at the level of WebGPU/wgpu-py.

It sounds to me that Qt created their own abstraction over Vulkan and co, because wgpu did not exist yet.

I can't really compare them from a technical pov, because I'd have to read more into QRhi. But QRhi is obviously tight to / geared towards Qt, which has advantages, as well as disadvantages.

Wgpu is more geared towards the web, so it likely has more attention to e.g. safety. WebGPU is also based on a specification, there is a spec for the JS API as well as a spec for webgpu.h. There's actually two implementations (that I know of) that implement webgpu.h: wgpu-native (which runs WebGPU in firefox) and Dawn (which runs WebGPU in Chrome).

link