Super. Good. Code.
I got a request recently to fix up the WebGL Aquarium demo. I’ve had this bookmarked for a while since it’s one of the only test cases for GL_EXT_multisampled_render_to_texture I’m aware of, at least when running Chrome in EGL mode.
Today, a brief post and lamentation.
I posted yesterday in brief about zink on nvidia blob, But what actually was necessary to get this working?
Thanks once again to my generous sponsors at Valve, as well as a patch from a GLX guru with the very accurate commit log “I hate everything.”, I put in a little time today and came up with this:
This is the journey of how zink-wip went from 0 fps in RPCS3 to a bit more than that. Quite a bit more, in fact, if you’re using RADV.
I keep saying this, but I feel like I’m progressively getting further away from the original goal of this blog, which was to talk about actual code that I’m writing and not just create great graphics memes. So today it’s once again a return to the roots and the code that I had intended to talk about yesterday.
Optimizing transfer_map is one of the first issues I created, and it’s definitely one of the most important, at least as it pertains to unit tests. So many unit tests perform reads on buffers that it’s crucial to ensure no unnecessary flushing or stalling is happening here.
One thing that’s everywhere in mesa (at least outside of mesa core) is enum pipe_format. This enum is used to describe image formats. The general way that it works is that there’s a hook in struct pipe_screen:
/**
* Check if the given pipe_format is supported as a texture or
* drawing surface.
* \param bindings bitmask of PIPE_BIND_*
*/
bool (*is_format_supported)( struct pipe_screen *,
enum pipe_format format,
enum pipe_texture_target target,
unsigned sample_count,
unsigned storage_sample_count,
unsigned bindings );
Each gallium driver implements this hook, and then gallium queries the driver before creating a resource using a given format and then also before using a created resource in various ways.
I’m back, and today’s topic is testing.
Today I’m going to briefly go over a big-ish API change that’s taking place as a result of a MR from Jason Ekstrand.
I’ve been blogging pretty in-depth about Zink and related code for a while, so let’s do a quick roundup with some future blog post spoilers.
It’s time to finish up UBO support in this long form patch review blog series. Here’s where the current progress has left things:
Yesterday I covered the problems related to handling gl_PointSize during the SPIR-V conversion. But there were still more problems to overcome.
This xfb blog series has gone on for a while now, and it’d be great if it ended soon. Unfortunately, there’s a lot of corner cases which are being found by piglit, and the work and fixing continue.
Stream output is another name for xfb closer to the driver level. Inside mesa (and gallium), we’ll commonly see different types related to struct pipe_stream_output_* which provide info about how the xfb info is output to its corresponding buffers.
After getting the extensions and features enabled so things would run (more on this in a future post), I dove into the deep end of ntv because I was getting some crazy assert() errors.
After years of using one blog, then using a number of different blogs, then not blogging at all, I’m now blogging once more. Currently, the plan is to focus on mesa code that I’m working on, specifically (at least for now) zink code.