[libre-riscv-dev] New Resources/Specifications Page Created

Jacob Lifshay programmerjake at gmail.com
Sun Sep 15 21:14:46 BST 2019


On Sun, Sep 15, 2019, 08:58 Michael Pham <pham.michael.98 at gmail.com> wrote:

> On Sun, Sep 15, 2019 at 9:00 AM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> >
> > On Sunday, September 15, 2019, Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > > > Note: I'm not sure what the plan is for OpenGL. Are we doing that in
> > > hardware or using Zink to run OpenGL on top of Vulkan?
> > >
> > > To answer your question, Michael:
> > > We were planning on just implementing Vulkan (and maybe OpenCL) and
> > > relying on Zink, SwiftShader (which should also work on GNU/Linux),
> > > and other similar projects that translate other APIs to Vulkan.
> >
> >
> > That last link you added Michael is really cool it lists a stack of
> > projects that implement Vulkan adapters.
> >
> > DirectX, OpenCL, OpenGL ES 2 and 3, tons more.
> >
> > L.
> >
>
> Yes, it's really cool to see all these projects to get other APIs to
> run on top of Vulkan, even Khronos in one of their slides said Vulkan
> can serve as an Hardware Abstraction Layer.
>
> However, while it makes sense to emulate other graphics APIs, for
> example DirectX-->Vulkan and OpenGL-->Vulkan, OpenCL is wildly
> different from Vulkan: some stuff can be done in OpenCL that cannot be
> done in Vulkan and vice versa https://stackoverflow.com/a/40705151 .
>

Yeah, I've been thinking it might be a good idea to implement a Vulkan
extension that supports OpenCL compute shaders using OpenCL semantics for
operations, allowing there to be a common OpenCL implementation for Kazan
and anyone else who implements that extension. As far as I know, that's the
only missing feature in Vulkan that would allow OpenCL to be efficiently
implemented on top of Vulkan.

Jacob


More information about the libre-riscv-dev mailing list