Thanks, this looks reasonable given the differences in the backends for these shaders.
More general, is there a commited roadmap for QRhi? Is it "safe" to start using it in applications with a long lifetime, or can we risk it being deprecated and development stopped like Qt3D? Since it is the foundation for Qt Quick (3D) I this risk to be reduced. But is it being actively developed and improved? I am still considering which library to replace Qt3D with. Quick 3D is not an option. Vulkan is an obvious candidate, but it would be nice with D3D and Metal support as well, and it is so low level. Bgfx is a nice alternative, quite similar to QRhi, but mainly driven by a single developer, which makes it risky. So QRhi currently looks like a good option. What are good arguments for _not_ going for QRhi? Thanks, Harald lør. 21. des. 2024, 11:32 skrev Giuseppe D'Angelo via Development < development@qt-project.org>: > Hello, > > On 21/12/2024 09:18, Harald Vistnes wrote: > > > > I've seen some notes that geometry shaders are not supported in QRhi, > > but I don't know if that is outdated or not. Can geometry and > > tessellation shaders be used with QRhi? > > Yes, although with lots of limitations, and they're still > half-experimental so YMMV. > > See the descriptions of QRhi::Tessellation and Geometry at > https://doc.qt.io/qt-6/qrhi.html . > > Thanks, > > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - Trusted Software Excellence > > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development >
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
