-
Notifications
You must be signed in to change notification settings - Fork 152
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
GFX-HAL as a graphics backend #129
Comments
First of all, thanks for reaching out! We definitely want integration with GFX. The development of gfx-hal and its kinda difficult low-level api surface and also much more pressing problems were delaying it. So anyone, who wants to start working on it, is highly welcome.
In theory yes. In practice however headless is sometimes not really headless, but still depends on some kind of graphical system. And the much bigger issue at hand is, that this might be really slow. Because without integration with the native buffer types we would likely need to copy the rendered image out of the GPU to the CPU and back to the framebuffer of the GPU. I do not know, if gfx-hal's api does give us the possibility of directly mapping a rendered buffer from the headless instance. It does not look that way and I am not in favor of this approach anyway.
This is the right way forward. gfx-hal's backends seem to be very focused on certain windows systems though and this has to be lifted and become trait-based. E.g. the The But not the one we actually want to have, which is the We could do this by implementing our own backend, but that is a huge deal, completely unnecessary and would likely duplicate a lot of code. But we might get away with implementing our own backend, re-using all types of What I would actually like to see is a change of the gfx-backend-apis. Creation of those types should not depend on specific types of e.g. The way forward would likely be:
|
First of all, thanks for such a detailed response! In my opinion, hacking together support for gfx_backend_gl can be very helpful to start experimenting with different already existing renderers, as well as trying to implement new ones. This will also allow to theoretically compare performance of Smithay GFX rendering vs Wayland/X11 GFX rendering. Also, I would have loved to spend some time on it during this weekend, but I feel like I would be able to get much further with some mentoring on the matter. |
Sure thing. So for the smithay side, what you want to support is objects implementing the You will most likely need all of those six methods at some point in You will need to provide an alternative to the
I have no idea, where
Last functions are |
@Drakulix, ok, thanks for the info, I will notify you as soon as I get to it! Also, a couple of questions for now:
|
IIUC, it would actually be the other way around : make gfx-hal use smithay as its GL provider. This would make it possible to use projects like rendy to draw the framebuffer contents in a context managed by smithay. |
@skyne98 wrt to gfx-rs support, in a first step focusing on openGL. The gfx-backend-gl crate requires you to provide a Ideally, gfx-backend-gl would abstract its needs from glutin behind a trait, which would let smithay provide an implementation of this trait, like for |
@vberger but why should we worry about this? Why not provide a whole-new backend for gfx-rs which uses glium (gfx-backend-smithay-gl)? I think making a duplicate of gfx-backend-gl and rewriting it to use another OpenGL library should be pretty straightforward? |
Oh yes, writing such a backend would work, if you're willing to put the effort of maintaining a fork of gfx-backend-gl with smithay swapped for glutin. I suggested working with gfx-rs to make gfx-backend-gl generic over gl providers because it seems to be much less effort in the long run. |
Have anyone talked to them in regards to this? Or should I feel free to start a discussion there? |
I think you can start the discussion. 👍 |
Hey there! What about building a gfx-hal based graphics backend for smithay?
In theory, it should be possible to use gfx-hal for headless drawing, mapping the resulting image to the framebuffer via DRM or EGL, right? Sorry, I am still diving deep into this stuff, but seems logical to me.
The backend itself can provide a surface for creation of FrameBuffer, etc.
If it is possible, I would be interested in trying to implement it as soon as I get my GFX-HAL-based 2D renderer running to gain some experience 🤷♂️.
Also, maybe there is an option to extend the gfx backends themselves to allow creating surfaces/instances from, for example, EGL streams? Or maybe somehow connect two projects.
Thanks for your time!
The text was updated successfully, but these errors were encountered: