alacritty
alacritty copied to clipboard
alacritty
Add a Vulkan Renderer
https://forum.manjaro.org/t/alacritty-a-gpu-accelerated-terminal-emulator/15234
and as Tids says: Why not vulkan?
I don't think there is any real reason to use Vulkan for this sort of application. It already runs at a very high frame rate that the extra work to get Vulkan working wouldn't really provide any real benefit.
I'm hoping to have a Vulkan renderer at some point, but OpenGL made sense as an initial target since it's supported everywhere Alacritty cares about.
I think that what @CarwynNelson said is probably accurate, it's very possible that Vulkan would provide no benefit in performance while being a lot of work to get going and working everywhere.
However I'd love to be surprised by this, but I don't think there's any kind of priority on testing this out (which is why this has the "P - low" tag).
If there is a vulkan renderer in the future though it would be nice to use something like MoltenVK (or whatever is available when that happens).
I've read the same thing @Avi-D-coder. For now that probably doesn't change much, because I don't expect MacOS to drop OpenGL in under a year. However it would probably still be a good idea to have a long-term plan on how to fix this.
@jwilm
OpenGL made sense as an initial target since it's supported everywhere Alacritty cares about.
We'd love to use alacritty on Fuchsia, but we don't have support for OpenGL. If you can provide mentoring instructions, I'm sure there are folks at Google who would be interested in helping to add support!
I can't speak for jwilm but I think any help would be greatly appreciated!
If it is desired to support multiple different render backends without having to implement everything over and over again it could also pay off to look into something like gfx-rs.
Have you looked into these?
- https://github.com/MaikKlein/ash
- https://github.com/vulkano-rs/vulkano
I've done some reading around gfx-rs and https://github.com/gfx-rs/wgpu seems very interesting and promising.
I feel like changing Vulkan to OpenGL won't gain much for us, however using gfx-rs makes the most sense for us, if we want to support macOS via Metal or provide an option to pick OpenGL/Vulkan on Linux/Windows. So, while Vulkan is nice, I don't see any point in changing our rendering to anything other than gfx-rs.
The biggest problem with both gfx-rs and wgpu is that both lack good OpenGL support. Which will likely always be our primary focus. So an API that doesn't properly support this is not very useful to us.
The biggest problem with both
gfx-rsandwgpuis that both lack good OpenGL support. Which will likely always be our primary focus. So an API that doesn't properly support this is not very useful to us.
Why does Alacritty need OpenGL support so badly? Wouldn't it be more performant (and modern) to use wgpu, since it abstracts away the 3 major graphics APIs (Vulkan, Metal, DirectX) anyway? It also provides first class Rust support, apparently.
Why does Alacritty need OpenGL support so badly? Wouldn't it be more performant (and modern) to use wgpu, since it abstracts away the 3 major graphics APIs (Vulkan, Metal, DirectX) anyway? It also provides first class Rust support, apparently.
Alacritty was written with OpenGL before wgpu existed iirc.
Why does Alacritty need OpenGL support so badly? Wouldn't it be more performant (and modern) to use wgpu, since it abstracts away the 3 major graphics APIs (Vulkan, Metal, DirectX) anyway?
Why do you think that abstractions would make things more performant? It's usually the opposite way around.
OpenGL is the best target because "newer" APIs are useless to Alacritty and OpenGL has much better compatibility with old hardware. Basically no reason not to use OpenGL really.
i run neovim on tmux on alacritty and am wondering about 3d rendering within this setup -- i'd like to build or find some way to edit and view wireframe meshes/3d objects, rotate/zoom/interact with vim keys, as well as view audio signal spectrums, manipulate audio samples, etc without leaving the alacritty instance or relying on the host windowing system.
what do you folks think of this use case? is there a fluid way to perform these operations or is it something which has yet to be unearthed?
what do you folks think of this use case? is there a fluid way to perform these operations or is it something which has yet to be unearthed?
It's completely inappropriate for a terminal emulator.
it may be completely inappropriate for your terminal emulator, but not for mine
Well, Alacritty is mine. :wink:
Of course I won't come after you if you decide to implement it yourself in your own fork. That's what forking is for after all.
fair enough in all respects. it is a wonderful piece of software which is why i use it -- the fastest component out there by my count.
i read this thread about integrating vulkan, other gpu layers and considered that you folks may understand deeply what i might need to do to achieve this sort of function, even though it is not the common use case.
it is useful to me even though it is perhaps not useful to you
Well, Alacritty is mine. 😉
Alacritty is also my terminal. Just saying.
Seriously though, just because we look at GPUs to render 2D graphics doesn't mean we have anything to do with 3D graphics. I think on principle, a terminal emulator is fundamentally a 2D tool for rendering a text based interface. Any discussion outside these bounds is sure to meet resistance. Just look at the fate of image rendering in the terminal for a good example.
@klebs6, perhaps look more into Rust GPU libraries instead of application projects.
Closing because this is a non-goal. If someone ever bothers to write a Vulkan renderer feel free to send a patch, but currently we already have two different OpenGL renderers and that strikes a very good balance between GPU support and performance. Writing a Vulkan renderer would neither improve performance nor support much.
They currently massively outperform alacritty on vtebench which makes it an interesting watch to see how this changes further into development
They currently massively outperform alacritty on vtebench which makes it an interesting watch to see how this changes further into development
This means absolutely nothing. The things you should be comparing are render times, not vtebench. Vtebench only benchmarks the parser which is identical in both. In fact a significantly slower terminal would often perform better than a faster one, since it has to interrupt the parser less.
They currently massively outperform alacritty on vtebench which makes it an interesting watch to see how this changes further into development
if one alacritty_terminal outperforms other alacritty_terminal it should at least provide a link to how it was setup, but cosmic term has rather slow render.
I wasn't saying as the end all be all (although you seem to heavily rely on it) (and I tend to like my terminal to load as fast as possible anyway so I can immediately initiate commands) . It was more an interest to see how it may develop to see if vulkan shows worthy improvement opengl in terms of 2d rendering a terminal (which is why I didn't bother quoting numbers).
alacritty renders like ~1000 frames(simple scenes) and ~400(complex scenes) per second with A750 and even achieves 60fps on low end arm boards where vulkan doesn't exist.
I'm not against using e.g. wgpu because OpenGL is wacky on macOS/Windows, but it's a different matter and I'd rather focus on OpenGL side of things for now.