crashes with wivrn #33

New Issue

2025-01-12T18:42:15-05:00

birdguy-cs commented

2025-01-12 18:42:15 -05:00

(Migrated from github.com)

For me it crashes when installed on manjaro via the AUR, when i load it shows a black screen for a couple seconds and then closes.

technobaboo commented

2025-01-12 18:43:16 -05:00

(Migrated from github.com)

are you using a nvidia gpu by any chance?

birdguy-cs commented

2025-01-12 18:52:27 -05:00

(Migrated from github.com)

yea

AlphaCraft9658 commented

2025-07-20 18:25:14 -04:00

(Migrated from github.com)

This happens on my system too. I installed it via Envision, but also from the Fedora Terra repository, and I am just getting a black screen, though I am running telescope, so it should have an actual output. There is an error in the output, which is constantly being thrown:

<timestamp> ERROR tokio-runtime-worker smithay::backend::renderer::gles: 358: [GL] GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElementsInstanced

Is this related to NVIDIA and the proprietary driver and is there any potential user-sided solution, or does some code in StardustXR need adjustment? It could also be understandable that it's a bug in the actual driver which would require intervention by NVIDIA.

This happens on my system too. I installed it via Envision, but also from the Fedora Terra repository, and I am just getting a black screen, though I am running telescope, so it should have an actual output. There is an error in the output, which is constantly being thrown: ``` <timestamp> ERROR tokio-runtime-worker smithay::backend::renderer::gles: 358: [GL] GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElementsInstanced ``` Is this related to NVIDIA and the proprietary driver and is there any potential user-sided solution, or does some code in StardustXR need adjustment? It could also be understandable that it's a bug in the actual driver which would require intervention by NVIDIA.

technobaboo commented

2025-07-21 12:46:27 -04:00

(Migrated from github.com)

fundamentally idk why that happens... but i do know we are replacing GL entirely with vulkan so this problem should be categorically solved.... whenever we can figure out the bugs with bevy and our dmabufs/shm buffers (they flicker for some reason, the whole mesh doesn't render for some frames.... really frustrating)

so yeah... sorry it's taken so long and is so broken!! fundamentally, stereokit (the renderer we were using) wasn't built for Linux and I don't have the energy to maintain and update C-style C++ code that barely builds with gcc/clang (it was made for msvc)... and GL doesn't let you precisely pick which GPU to use so multigpu issues and all, it was time for a refactor anyway. On the discord you can see us working on the bug in the new bevy version...

so sorry, we're working on it! if you know bevy or such we'd appreciate help too
On Sunday, July 20th, 2025 at 6:25 PM, Alpha-Craft @.***> wrote:

AlphaCraft9658 left a comment (StardustXR/server#33)

This happens on my system too. I installed it via Envision, but also from the Fedora Terra repository, and I am just getting a black screen, though I am running telescope, so it should have an actual output. There is an error in the output, which is constantly being thrown:

ERROR tokio-runtime-worker smithay::backend::renderer::gles: 358: [GL] GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElementsInstanced

Is this related to NVIDIA and the proprietary driver and is there any potential user-sided solution, or does some code in StardustXR need adjustment? It could also be understandable that it's a bug in the actual driver which would require intervention by NVIDIA.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

fundamentally idk why that happens... but i do know we are replacing GL entirely with vulkan so this problem should be categorically solved.... whenever we can figure out the bugs with bevy and our dmabufs/shm buffers (they flicker for some reason, the whole mesh doesn't render for some frames.... really frustrating) so yeah... sorry it's taken so long and is so broken!! fundamentally, stereokit (the renderer we were using) wasn't built for Linux and I don't have the energy to maintain and update C-style C++ code that barely builds with gcc/clang (it was made for msvc)... and GL doesn't let you precisely pick which GPU to use so multigpu issues and all, it was time for a refactor anyway. On the discord you can see us working on the bug in the new bevy version... so sorry, we're working on it! if you know bevy or such we'd appreciate help too On Sunday, July 20th, 2025 at 6:25 PM, Alpha-Craft ***@***.***> wrote: > AlphaCraft9658 left a comment [(StardustXR/server#33)](https://github.com/StardustXR/server/issues/33#issuecomment-3094830554) > > This happens on my system too. I installed it via Envision, but also from the Fedora Terra repository, and I am just getting a black screen, though I am running telescope, so it should have an actual output. There is an error in the output, which is constantly being thrown: > > <timestamp> ERROR tokio-runtime-worker smithay::backend::renderer::gles: 358: [GL] GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElementsInstanced > > Is this related to NVIDIA and the proprietary driver and is there any potential user-sided solution, or does some code in StardustXR need adjustment? It could also be understandable that it's a bug in the actual driver which would require intervention by NVIDIA. > > — > Reply to this email directly, [view it on GitHub](https://github.com/StardustXR/server/issues/33#issuecomment-3094830554), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABCU4ECXFTR5MAU2QEZGTZT3JQJN7AVCNFSM6AAAAABVBQBRGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOJUHAZTANJVGQ). > You are receiving this because you commented.Message ID: ***@***.***>

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: StardustXR/server#33