Closed hamoid closed 1 month ago
This library requires JDK 22 or later due to its use of the foreign memory access API.
Sorry, this is in the "Prerequisites" section of the library repository but not on this one. I'll update the README.
Readme has been updated.
Note : According to the log trace, you are running it with a JRE 17 instead of a JRE 22+
JDK Version | Class File Version |
---|---|
Java 8 | 52.0 |
Java 9 | 53.0 |
Java 10 | 54.0 |
Java 11 | 55.0 |
Java 12 | 56.0 |
Java 13 | 57.0 |
Java 14 | 58.0 |
Java 15 | 59.0 |
Java 16 | 60.0 |
Java 17 | 61.0 |
Java 18 | 62.0 |
Java 19 | 63.0 |
Java 20 | 64.0 |
Java 21 | 65.0 |
Java 22 | 66.0 |
Java 23 | 67.0 |
Java 24 | 68.0 |
I have multiple JDK versions, including 22. Is it possible to specify in the Gradle build file which one to use? Otherwise I'll need to switch the default one in my OS.
If I do switch the default building works, but it doesn't run on this old laptop with LOG {3} Adapter Gl AdapterInfo { name: "Mesa Intel(R) HD Graphics 4600 (HSW GT2)", vendor: 32902, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "4.6 (Core Profile) Mesa 24.2.2-arch1.1", backend: Gl }
LOG {4} configuring surface with SurfaceConfiguration { usage: TextureUsages(COPY_SRC | RENDER_ATTACHMENT), format: Rgba8UnormSrgb, width: 800, height: 600, present_mode: Fifo, desired_maximum_frame_latency: 2, alpha_mode: Opaque, view_formats: [] }
thread '<unnamed>' panicked at src/lib.rs:582:5:
Error in wgpuSurfaceConfigure: Validation Error
Caused by:
Requested usage is not supported
I can provide full logs if interesting.
The log is enough, COPY_SRC or RENDER_ATTACHMENT is not suported which is odd.
Can you edit the file at shared/src/commonMain/kotlin/render.kt to replace
usage = setOf(TextureUsage.renderattachment, TextureUsage.copysrc),
by
usage = setOf(TextureUsage.renderattachment),
And then retry.
Could you also check that your OpenGL version is supported :
Check also if your driver is up to date please.
Note regarding the Java version :
The easiest way to switch JDK to another on the flow is by using a tool like SDKMAN if you are a terminal user, but you can also export the path of the required JDK on JAVA_HOME on your current terminal session.
Personally, I prefer using IntelliJ, which allows you to configure the JDK on a project-by-project basis :
Thank you. With that change it does start and render 🥳 Although it logs the following per animation frame:
LOG {5} Device after submission 489
LOG {3} Device::maintain: waiting for submission index 488
LOG {4} Active submission 488 is done
LOG {5} Destroy raw StagingBuffer
LOG {5} Queue::submit to Id(0,1,gl) returned submit index 489
LOG {4} Removing swapchain texture Id(2,489,gl) from the device tracker
LOG {5} User is removing TextureId(2,489,gl)
LOG {4} Presented. End of Frame
LOG {5} Queue::write_buffer Id(1,1,gl) 64bytes
LOG {5} buf 1: transition BufferUses(UNIFORM) -> BufferUses(COPY_DST)
LOG {5} tex 491: insert start TextureUses(UNINITIALIZED)
LOG {5} User is inserting TextureId(2,490,gl)
LOG {4} Created CURRENT Surface Texture Id(2,490,gl)
LOG {4} Create view for Texture with '<Surface Texture>' label filters usages to Textu reUses(COLOR_TARGET)
LOG {5} User is inserting TextureViewId(491,1,gl)
LOG {5} Texture::create_view(Id(2,490,gl)) -> Id(491,1,gl)
LOG {5} User is inserting CommandBufferId(489,1,gl)
LOG {5} Device::create_command_encoder -> Id(489,1,gl)
render pass descriptor MemorySegment{ address: 0x7a2af842b1a0, byteSize: 56 }
color attachments MemorySegment{ address: 0x7a2af8415dd0, byteSize: 72 }
color attachment MemorySegment{ address: 0x7a2af8415dd0, byteSize: 72 }
LOG {2} Depth slice on color attachments is not implemented
LOG {5} Encoding render pass begin in CommandBuffer with '' label
LOG {5} RenderPass::set_pipeline RenderPipeline with '' label
LOG {5} RenderPass::set_bind_group 0 BindGroup with '' label
LOG {5} buf 1: insert BufferUses(UNIFORM)..BufferUses(UNIFORM)
LOG {5} Binding [0] = group BindGroup with '' label
LOG {5} RenderPass::set_vertex_buffer 0 Buffer with '' label
LOG {5} buf 0: insert BufferUses(VERTEX)..BufferUses(VERTEX)
LOG {5} RenderPass::draw 36 1 0 0
LOG {5} Merging renderpass into CommandBuffer with '' label
LOG {5} tex 0: insert start TextureUses(DEPTH_STENCIL_WRITE)
LOG {5} tex 491: insert start TextureUses(COLOR_TARGET)
LOG {5} buf 0: insert BufferUses(VERTEX)..BufferUses(VERTEX)
LOG {5} buf 1: insert BufferUses(UNIFORM)..BufferUses(UNIFORM)
LOG {5} tex 0: insert start TextureUses(DEPTH_STENCIL_WRITE)
LOG {5} tex 491: insert start TextureUses(COLOR_TARGET)
LOG {5} Command buffer Id(489,1,gl)
LOG {5} Queue::submit Id(0,1,gl)
LOG {5} tex 491: insert start TextureUses(PRESENT)
LOG {5} Extracting BakedCommands from CommandBuffer with '' label
LOG {5} Drop CommandBuffer with '' label
LOG {5} Stitching command buffer Id(489,1,gl) before submission
LOG {5} buf 1: transition BufferUses(COPY_DST) -> BufferUses(UNIFORM)
LOG {5} tex 491: transition simple TextureUses(UNINITIALIZED) -> TextureUses(C OLOR_TARGET)
LOG {5} tex 491: transition simple TextureUses(COLOR_TARGET) -> TextureUses(PR ESENT)
$ glxinfo | grep OpenGL
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 4600 (HSW GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.2.2-arch1.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.2.2-arch1.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.2.2-arch1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
I'm on ArchLinux (rolling distro) so I hope the driver is up-to-date.
OpenGL support is more limited than Vulkan/DirectX12 and Metal, so you might encounter some features that don't work. After the release of WebGPU 1.0, OpenGL support may improve.
I'm closing this ticket because removing the COPY_SRC fixed the issue, but this means you can't use the render result to copy it to a texture or buffer. (For example, to take a screenshot or do post rendering effects)
Feel free to create a new ticket if you encounter more compatibility issues. Thanks for the feedback anyway.
First issue :-) Maybe almost running?