search

LWJGL / lwjgl3

LWJGL is a Java library that enables cross-platform access to popular native APIs useful in the development of graphics (OpenGL, Vulkan, bgfx), audio (OpenAL, Opus), parallel computing (OpenCL, CUDA) and XR (OpenVR, LibOVR, OpenXR) applications.
https://www.lwjgl.org
BSD 3-Clause "New" or "Revised" License
4.75k stars 635 forks source link

Vulkan SC #874

Open tlf30 opened 1 year ago

tlf30 commented 1 year ago

Library

Vulkan SC

Project page

https://www.khronos.org/vulkansc/

Source repository

https://github.com/KhronosGroup/VulkanSC-Docs

Platforms

Windows x64

Description

Hello @Spasi, I have been roped into a project that needs (wants) to run Vulkan SC inside of Java. I know you are going to be changing gears to LWJGL 4 now that the latest LWJGL 3.3.2 is out, but I was wondering if you would consider adding VulkanSC bindings to LWJGL 3? (Or even LWJGL 4 if you are no longer going to do any releases to 3) Until then we will probably move forward with regular vulkan for prototyping, but limiting our functions to be able to smoothly transition to SC.

Thanks, Trevor

Spasi commented 1 year ago

Hey @tlf30,

Supporting SC as completely separate bindings would be too much I think. Would you be OK with simply exposing whatever functions/tokens SC introduces over standard Vulkan? Afaict, most of everything else remains the same (except the unavailable functionality).

ws909 commented 1 year ago

@Spasi Would that be introduced in a manner which makes the border between normal and SC very blurry? For instance, while writing code using normal Vulkan, the IDE would suggest SC tokens unavailable in normal Vulkan? This could be rather confusing.

Spasi commented 1 year ago

@ws909 Yes.

ws909 commented 1 year ago

@Spasi Then I am not in favour of this approach.

Another module isn't needed, but I prefer that the existing VK classes are not polluted. Can the new tokens be added to a VKSC class hierarchy? The lack of multi-inheritance requires these classes not to inherit from VK10.

org.lwjgl.vulkan.sc.VKSC12.

Edit: or another module with a transitive dependency on the Vulkan module?

tlf30 commented 1 year ago

I also agree. While they could be the same module, they would at least need to be completely separate classpaths without crossover. There is a lot of functionality in regular vulkan that is not available in SC, and SC features not in regular. It would be very confusing if SC classes were mixed with regular classes. Complete seperation would be a requirement, even if in the same module.

EDIT: TO expand on this. anything from the VK10 class that is supported in SC should be duplicated into say a VKSC10, this removes confusion of things in VK10 that SC does not support. In a SC project, there should only be SC references and in a non-SC project there should be no SC references.