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

Vulkan Backend Thoughts #7

Open
mokafolio opened this issue Jul 8, 2018 · 0 comments
Open

Vulkan Backend Thoughts #7

mokafolio opened this issue Jul 8, 2018 · 0 comments

Comments

@mokafolio
Copy link
Owner

mokafolio commented Jul 8, 2018

I am currently starting to wrap my head around Vulkan and would like to begin working on a backend for Tarp at some point later this year because it appears to be a very portable solution that will work for Linux/Windows/Android/OSX & IOS (using LunarG/MoltenVK).
Before I do, I'd like to use this thread to put some thoughts out there in order to get feedback!

One of the questions in my mind is how to deal with all the extra verbosity that Vulkan introduces in terms of Devices/Queues/SwapChains etc. that are hidden away in OpenGL and other ancient GPU APIs. My thinking right now is this:

  • tpContextCreate will create and own all the Vulkan specific objects under the hood using reasonable defaults.
  • There will be an alternate context creation function called something like tpVkContextCreate that allows you to pass in the Vulkan primitives needed. This seems useful if you are already rendering things using Vulkan in your application and want to use the same GPU etc. for Tarp. In that case, you'd also maintain ownership of those primitives.
  • Another function like tpVkQueuePaththat allows you to explicitly all drawing commands needed to render a path to a vulkan queue could be useful.

I think this will be enough to maintain both, the simplicity of the opengl implementation on the users end, as well as the flexibility to integrate Tarp into an existing Vulkan environment.

The other thoughts I have are mainly regarding potential rendering ideas that might be interesting to test for the Vulkan backend:

  1. Test what's faster, queueing up all drawing commands/state changes for all the tpDrawPath related functions in between tpPrepareDrawing and tpFinishDrawing and submit them all at once to the GPU in tpFinishDrawing vs only drawing/rasterizing one path at a time.
  2. Compute stroke geometry and flatten paths in a Compute Shader? This seems somewhat interesting but might be tricky especially for strokes.

Generally speaking I will most likely start by reusing most of the CPU side code from the OpenGL implementation and translating it to Vulkan to then evaluate the two rendering suggestions mentioned above afterwards.

Please check out the caching API thoughts over here, too: #8

Any thoughts and ideas welcome!

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

No branches or pull requests

1 participant