llvmpipe is OpenGL 4.5 conformant.

(I just sent the below email to mesa3d developer list).

Just to let everyone know, a month ago I submitted the 20.2 llvmpipe
driver for OpenGL 4.5 conformance under the SPI/X.org umbrella, and it
is now official[1].

Thanks to everyone who helped me drive this forward, and to all the
contributors both to llvmpipe and the general Mesa stack that enabled
this.

Big shout out to Roland Scheidegger for helping review the mountain of
patches I produced in this effort.

My next plans involved submitting lavapipe for Vulkan 1.0, it's at 99%
or so CTS, but there are line drawing, sampler accuracy and some snorm
blending failure I have to work out.
I also ran the OpenCL 3.0 conformance suite against clover/llvmpipe
yesterday and have some vague hopes of driving that to some sort of
completion.

(for GL 4.6 only texture anisotropy is really missing, I've got
patches for SPIR-V support, in case someone was feeling adventurous).

Dave.

[1] https://www.khronos.org/conformance/adopters/conformant-products/opengl#submission_272

Comments

  1. xutianchun4 May 2023 at 04:02

    I installed mesa 20.2.0 in my Linux server: meson setup builddir -Dosmesa=gallium -Dgallium-drivers=swrast,swr -Dvulkan-drivers=[] ninja -C builddir install And I want to run OpenGL compute shader in CPU, but it seems that the OpenGL version is 3.1, compute shader is not support. Dose the llvmpipe supports compute shader? And how can I to use it to run compute shader?

    Other information:
    1. I query the OpenGL version using glGetIntegerv(GL_MAJOR_VERSION, &version_major_);glGetIntegerv(GL_MINOR_VERSION, &version_minor_); And what I got is 3.1
    2. the glGetString(GL_RENDERER) returns: llvmpipe (LLVM 7.0.1, 256 bits)
    3. glGetString(GL_VENDOR) returns: vendor: Mesa/X.org
    4. the glCreateShader(GL_COMPUTE_SHADER) cause OpenGL error, the OpenGL error code is 0x500 and got error message:
    Mesa: User error: GL_INVALID_ENUM in glCreateShader(GL_COMPUTE_SHADER)

    ReplyDelete

Post a Comment

Popular posts from this blog

On Rust, Linux, developers, maintainers

There's been a couple of mentions of Rust4Linux in the past week or two, one from Linus on the speed of engagement and one about Wedson departing the project due to non-technical concerns. This got me thinking about project phases and developer types. Archetypes: I will regret making an analogy, in an area I have no experience in, but let's give it a go with a road building analogy.   Let's sort developers into 3 rough categories. Let's preface by saying not all developers fit in a single category throughout their careers, and some developers can do different roles on different projects, or on the same project simultaneously. 1. Wayfinders/Mapmakers I want to go build a hotel somewhere but there exists no map or path. I need to travel through a bunch of mountains, valleys, rivers, weather, animals, friendly humans, antagonistic humans and some unknowns. I don't care deeply about them, I want to make a path to where I want to go. I hit a roadblock, I don't focus
Read more

radv: vulkan video encode status

Vulkan 1.3.274 moves the Vulkan encode work out of BETA and moves h264 and h265 into KHR extensions. radv support for the Vulkan video encode extensions has been in progress for a while. The latest branch is at [1]. This branch has been updated for the new final headers. Updated: It passes all of h265 CTS now, but it is failing one h264 test. Initial ffmpeg support is [2]. [1] https://gitlab.freedesktop.org/airlied/mesa/-/tree/radv-vulkan-video-encode-h2645-spec-latest?ref_type=heads [2] https://github.com/cyanreg/FFmpeg/commits/vulkan/
Read more

radv: vulkan av1 video decode status

The Khronos Group announced VK_KHR_video_decode_av1 [1], this extension adds AV1 decoding to the Vulkan specification. There is a radv branch [2] and merge request [3]. I did some AV1 work on this in the past, but I need to take some time to see if it has made any progress since. I'll post an ANV update once I figure that out. This extension is one of the ones I've been wanting for a long time, since having royalty-free codec is something I can actually care about and ship, as opposed to the painful ones. I started working on a MESA extension for this a year or so ago with Lynne from the ffmpeg project and we made great progress with it. We submitted that to Khronos and it has gone through the committee process and been refined and validated amongst the hardware vendors. I'd like to say thanks to Charlie Turner and Igalia for taking over a lot of the porting to the Khronos extension and fixing up bugs that their CTS development brought up. This is a great feature of having
Read more