Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🌋 #1

Open
absolutelynothelix opened this issue Mar 11, 2023 · 9 comments
Open

🌋 #1

absolutelynothelix opened this issue Mar 11, 2023 · 9 comments

Comments

@absolutelynothelix
Copy link
Owner

@absolutelynothelix
Copy link
Owner Author

absolutelynothelix commented Mar 11, 2023

the work on the vulkan backend is available here (maybe i should make it the default branch here?).

currently it's only initialization and deinitialization but it's better than nothing. there are three stubs: vk_bind_pixmap supposed to bind a pixmap to a vulkan_image structure (i believe that i'll name it this way), vk_create_shadow_context and vk_destroy_shadow_context supposed to create and destroy a shadow context (the vulkan_shadow_context structure) obviously.

the vk_create_shadow_context stub is here only to avoid a segmentation fault because it's one of the first backend operations that are called no matter what during backend initialization. having it returning NULL results in a "graceful" exit because of backend initialization failure rather than a segmentation fault. the vk_destroy_shadow_context stub is here only for the symmetry with the vk_create_shadow_context stub.

it's too early to make even a draft pull request. the goal is to make it work with an empty configuration file.

currently i want to implement the vk_bind_pixmap function. i tried the x dri3 extension but the nvidia driver doesn't implement it and the nouveau driver doesn't implement vulkan at all (at least for now because of the work of the nvk driver), so i believe the first implementation will bind pixmaps using the x shm extension that should work for everyone. however, having the x dri3 extension support is a good idea and ideally the backend should try it first and if it fails fallback to the x shm extension without user interaction.

also, currently the code is manually formatted to match my style. vulkan is a long boi, my names are long bois and i don't like how clang-format handles all of this. anyway, it's too early to think about such things. if you want to make a pull request you may use whatever style and naming you like, i’ll fix it later, the most important thing is logic.

currently i'm relocating and i won't be able to work on the vulkan backend for maybe two or three weeks (i have a lot of other things to do), but i should be able to discuss it here so any opinions, ideas and even pull requests are appreciated. also, i'm not sure if i'll be able to complete it so at some point someone may have to take it over.

@absolutelynothelix
Copy link
Owner Author

absolutelynothelix commented Apr 15, 2023

i'm back! the vk_bind_pixmap implementation using the x shm extension is in progress.

i had no idea how to mark an absolutely ugly and unformattable piece of code, so:
image

edit: i managed to format it! though i still need to decipher it.

@absolutelynothelix
Copy link
Owner Author

absolutelynothelix commented Apr 19, 2023

isn't that pog?!

2023-04-23.17-27-12.mp4

@absolutelynothelix absolutelynothelix changed the title 🌋 🌋 Apr 23, 2023
@absolutelynothelix
Copy link
Owner Author

absolutelynothelix commented Apr 23, 2023

at this point i've reviewed and refactored all the code and squashed all the commits into the single one.

to get actual windows contents drawn on the screen we'll need shaders. unfortunately, vulkan can't compile shaders at runtime so i'll try to use the libshaderc to achieve this since i don't like the idea of having compiled shaders in the source tree.

@absolutelynothelix
Copy link
Owner Author

ISN'T THAT POG?!

2023-04-25.22-55-12.mp4

@absolutelynothelix
Copy link
Owner Author

send help
image

@absolutelynothelix
Copy link
Owner Author

yay, i managed to fix distorted windows' contents and update it properly!

2023-05-01.16-17-05.mp4

@absolutelynothelix
Copy link
Owner Author

now the vsync option is supported. if it set to false (--no-vsync) the VK_PRESENT_MODE_IMMEDIATE_KHR is used and when it set to true (--vsync) the VK_PRESENT_MODE_FIFO_KHR is used.

i prefer VK_PRESENT_MODE_FIFO_KHR over VK_PRESENT_MODE_MAILBOX_KHR because according to the spec it must be supported by the driver (so it should always be available) and it has the same behavior as glXSwapInterval(1) and eglSwapInterval(1) that are currently used in glx and egl backends correspondingly for vsync.

@absolutelynothelix
Copy link
Owner Author

absolutelynothelix commented May 6, 2023

@yshui, i’ve been scratching my head for some time on what to use as the buffer age. vulkan doesn’t offer anything similar to glx’s/egl’s buffer age extensions. there is only the incremental present extension that is similar to (at least, not sure about glx) egl’s swap buffers with damage extension. do you have any ideas or maybe you’ve done a research on this before (because you were thinking about the vulkan backend)? unfortunately, i can’t even find a decent read on this except corresponding extensions specifications.

also, there are «why?» comments on max buffer age set to 5 by default. i think it may be equal to number of buffers used, so for glx and egl it may be 2 and for xrender 2 or 3 depending on is double or triple buffering used.

edit: it seems that i can steal this code from the xrender backend, hehe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant