 Felly, gydweithio, hi, mae'n Neil Roberts ac mae'r gafodd ar y gafodd y gafodd y Gaelia. Mae'n gwellau o'r runnyn Gwneud. Mae'n gyffredinol gyda'r gwrthog. Felly, mae'r runnyn Gwneud? Felly, mae'n gweithio, ond mae'n gafodd gafodd gafodd gafodd gafodd gwasanaeth, mae'n gweithio'r gafodd, felly, mae'n gweithio'r gafodd gwasanaeth, mae'n gweithio'r gafodd gwasanaeth. Felly, Rana, Remedlove yn c unser bab y hykl hynnyintense running shaders oddi額ch i Hardan. Mae os iddyn nhw ac mae hi'n cwrthog yn gafodd gennyngas ac oedd glereadydd rhuna llywawr, yr hyn yn cael receivede ac rwy'n lle ei siwno hwyl mewn extrem rhai, mewn hyrtydd Llywodraeth me'i adwun hon nesaf i rwrn mwy. to run the shaders so VK runner is the same idea but for a Vulcan so you want it has tries to have the minimal overhead to write a test just with a simple script. So that's an example of a complete script so it has like the windows in the format with a section for each shader so in this case for the vertex shader I've just said vertex shader pass through that's just a shortcut to make a minimal vertex shader which just copies one attribute over to geo position. And then I've made a little fragment shader which just outputs green and then in the last section is the test section so it's a really high level language to just run some tests with the shader so in this case draw rect it just draws a full screen rectangle and then probe that probes the frame buffer for the color and then to run it. So it's just a standalone program you just run it with the name of the script on the command line and it tells you whether it works or not and in this case it didn't work because the shader wrote a green color out and then it's probing for a red color so it's telling you it got the wrong color. So behind the scenes so that's VK runner because on Vulcan it can't consume GLSL shaders obviously so it needs to consume SPERV shaders so VK runner compiles the GLSL shaders into SPERV by invoking GLSL line as an external process. And it creates pipelines for all of the state that it's needed to run the commands and it creates an offscreen frame buffer so unlike shader runner on Piglet so on the shader runner it uses the window system to create an actual X window or a Wailin window or whatever on VK runner because you don't necessarily need a window system for Vulcan. It just uses an offscreen buffer and then it puts all the test commands into a command buffer and executes them and then you can probe the result as one of the test commands. So just a bit of history, why did we start working on this? So Agalia has also been working on adding SPERV support to Intel's OpenGL driver so that's via the ARBGL SPERV extension so on the Intel I965 driver the compiler for OpenGL SPERV and Vulcan SPERV it's the same compiler. So we were testing the SPERV on OpenGL by converting a bunch of, by trying to automatically convert most of the shader runner tests in Piglet to SPERV so we had a script started by Nicolae Hanlite and we continued working on that to convert a huge amount of tests from Piglet into SPERV and I think that ended up testing quite a lot more of just the general SPERV compiler than it had been tested with the ChronoCTS test so it picked up a few more problems that perhaps weren't seen before. So when we ran into a problem on the OpenGL SPERV we often weren't sure whether that's a problem that we'd introduced on the SPERV extension or whether that was just an existing problem with the SPERV compiler so we really wanted a quick way to be able to run the shader tests that we had from a shader runner and run them with the Vulcan API as well. So yeah, so a vkrunner was just a way to try and have a utility that works as close as possible to the script format a shader runner but obviously just runs on Vulcan. Okay so it's not quite exactly the same script format because obviously Vulcan is a different API so it works slightly differently so for example on OpenGL there's a lot more API to query state about the shaders so for example when you compile a shader you can use the OpenGL API to query what uniforms are available and what the names are. But Vulcan you're expected to know what you've done so it doesn't give you any API to tell you what you did so we can't for example use uniform names in the test commands in the shader runner. So this is an example with shader runner using OpenGL so in the shader it's got these global uniforms and this is what everyone's used to I guess and so they're just in some sort of magic global namespace and the driver is expected to put them somewhere and they have names. In the test commands you can use the actual name you had there to set the value of the uniform and the shader runner uses the OpenGL API to get those names out. So with Vulcan that's not possible so to start with you can't just put uniforms in this magic global namespace you need to explicitly give a hint to the driver where to put them so in this case the simplest way to convert the shader is just to make a push constant block. And so once these are compiled and given to the driver the driver won't let you query the names as we're saying so to set the value in the test commands instead of setting the names there we set the just using the offsets into the uniform block. And that's also incidentally the same that happens when using SPOV on OpenGL the script that automatically. So shader runner I don't exactly know the history but I get the impression it's sort of started out quite small as it's grown organically over time and it's now quite a large single C file. So vehicle runner is written from scratch with a bit of hindsight so I've tried to like organize the code a bit more so like the code to pass the script is separated from the bits that execute it and so on. And also just because writing code for Vulcan it's a lot more verbose so obviously you just need to have a lot more code so keeping it all in one file is not practical. So I've also tried to make it so that a lot of commands are partially automatically generated so for example there's test commands to set all of the properties that are known on a pipeline. And so there's sort of automatically taken from the header file which describes the pipeline create info. So in vehicle runner there's a command for each member of the pipeline create info struct and it just sort of automatically puts the value in the right offset in the struct. And the same goes for the formats that it uses because in Vulcan it has a really nice enum for all the formats and they're structured in such a way that just looking at the name of the enum you can work out exactly how to store data in that format. So there's like a python script in vehicle runner to make a C table out of those enum names and then so then vehicle runner can work with all the formats and like so if you have your frame buffer in any format vehicle runner can use the C table to work out how to extract RGB values from that to probe the buffer. So some more examples show some more features of what vehicle runner can do. So as well as sections for writing the shaders and the test section and the same as with shader runner there's a section for writing your vertex buffer. So at the start of the section there's a header to describe the attributes and so the first part of each attribute is the location because in Vulcan you have to give an explicit location to each attribute and then the second part is the format name. So this is slightly different from shader runner in shader runner because the GL format names are a bit strange. It's easier in this case you can just use the actual format names from the Vulcan enum and that way it can support all of them. For compatibility vehicle runner can actually understand the piglet shader runner format as well. So once you've written the header there you can just write the values out for all your attributes and vehicle runner can use the C table to figure out how to pack them into the struct. So just to make it clear that those two attributes there that sets input for your vertex shader so in Vulcan you have to specify an explicit location and that specifies the input for those attributes there. So another section you can add you can add the indices so if you add the indices section you can just list your indices as numbers. So then in the test section if so just combining those that vertex data with the indices in the test section to actually draw something then you can just use the draw arrays command. You can say index to use the index buffer and then you can set the topology again using the GL enum. I think it supports the piglet enums as well to make it easier to convert piglet shader runner scripts. Then in this case I've decided another command as well so this is an example of what I was talking about with the automatically generated commands primitive restart enable that's the name of a member on the pipeline create infostruct. So setting that command just sets that member on the pipeline create infostruct to true and then whenever you execute a command vkrunner works out what pipelines are needed and creates all of the pipelines that are needed and then picks the right one to execute with that state that you described. And it's got obviously some defaults for the state so yeah try to pick sensible defaults so most of the time you don't need to set anything. So that script on the left that's just a combination of those previous examples I showed and if you run it outputs this messed up the Galio logo. So as I said there's no actual wincest so there's no actual window when you run vkrunner but there's an option to output the image if you do want to look at it so that's how I got that image. So another section there's a require section so this is also available in Piglet Shader Runner so you can just list an extension for example and when the vkrunner runs the test it will check that extension is available on the driver and if it's not available then the test will report skipped. So Piglet Shader Runner has already a convention to report either passed, skipped or fail so vkrunner copies the same convention so if the extension isn't available then it's skipped but also on Vulcan I'm just not sure you know you have to if you want to use an extension not only do you have to check for it you have to also enable it so vkrunner will do that as well. Unlike GL as well as extensions Vulcan has features so even things that are in core a lot of things are optional so there's a struct to enable to check for and enable features so the same thing is here just took the struct and converted them all into commands there so if you list any member of that struct it will check that the features available and if so it will enable it and you can also set the format of the frame buffer again using the format enums and the size so it supports all the shader stages so compute shaders as well obviously and so this is just a simple example using an SSBO and it fills in a table of square roots so instead of the draw command you just have a compute command. To dispatch the compute and then obviously it's not writing to the frame buffer so it's writing to an SSBO and you can just probe the values in the SPO so in all the previous examples all the shader sections were written in GLSL but if you want to you can also specify a shader section with SPERV source. So this is really useful if you want to test a corner case with SPERV because there's a lot of tests that you might want to test that you can't get the GLSL compiler to generate the SPERV that you want so VK runner has a command line option to when you run the test you can make it dump out the SPERV disassembly and then so you can grab that disassembly copy it back into your shader test and then. You can just modify it however you want to get the corner case that you wanted to test. So so as well as GLSL and SPERV shader sections you can also have a shader section which just literally lists the SPERV in binary format so obviously you don't want to write that by hand but there is a python script in the VK runner repo to batch convert all of your tests to binary. So I guess the main reason you'd want to do that is if you want to run on an embedded platform for example where putting GLSL line is not really practical. So once you run it through the script the test script looks like that. So the current status so it can do all the shader stages it can read and write from SSBOs and read from UBOs it can do vertex data and simple drawing and it can probe the frame buffer or SSBOs. It has a library so when you build it it builds a little static library with a public header so that it's useful if you want to integrate it into another test suite so it's quite self-explanatory I hope you just give it a source file and tell it to execute it and it will tell you if it worked or not. So far we've got VK runner has been integrated into the Vulcan CTS suite, the Kronos CTS suite. As far as I know there's currently only experimental tests I don't think there's any actual tests relying on it and that is using the API that I mentioned so that it can run the tests without forking any external processes. So it's also integrated into Piglet so Piglet has actual real tests on it now and it gets picked up by Intel's CI system so if you implement some Vulcan features and you want to make sure they don't get regressed the best way I think at the moment is to write. If it's a shader test then write it as a VK runner test and just drop it into the Piglet repo and if you just drop it anywhere under a certain directory it should get picked up so hopefully there's a really minimal barrier to adding shader tests for Vulcan. So well am I hoping to go with this? So it's missing quite a few features probably the main one which is quite bad is missing image and texture support. There's a poor request for this but I just need to review it and rebase it and make that happen. I've written a raise of buffer bindings because there's an issue open for it but there's probably a lot of other things missing as well. So on a branch there's like a user interface I'm not sure whether it's particularly useful but mostly just for fun. So it's just using GTK you can write the test script in the editor on the left and in the background it continuously runs the test and tells you whether it failed or not and shows you the image as a result. So sometimes in the past when I've been writing GL shader runner tests and it just says fail and it's quite a pain to keep tweaking all the data to get the image that you were expecting. So I was thinking it's quite nice maybe just to have a really tight feedback loop with the user interface. So there's another branch that's getting more silly. There's a branch for making animations. So this just adds a magic uniform to say the frame number and then you can run the test multiple times and it will generate the output into a video of IRFF MPEG. I just did this because it was kind of fun but if you know shader toys like a site where you can create lots of demos using WebGL and it's full of little animations it's quite easy just to convert those shader toy demos to run on VK runner to make like a sort of crazy offline shader toy. But yeah that's just for fun really. So there's another project called AMBA which Google are working on. I think they were inspired by VK runner so that might be an interesting project to watch to get to see where it's going to lead. So that's the github repo. It's got the same licences Meezer and Piglet. So I take a look. Thanks. Any questions? Yeah so I was wondering related to the video thing. In shader runner you can interleave probes with draw calls and quite a number of tests actually use that. Does that work there as well? It does work yes. There's some caveats because oh sorry the question was can you interleave probe and draw calls like you can in Piglet shader runner and the answer yes you can but there's a when you do a probe it flashes the command buffer that it was building up and then when you start another command it starts another command buffer. So it mostly works just transparently but there's some slight. You have to be aware that it's starting a new command buffer because when you start a new command buffer Vulcan loses a lot of state. So for example if you set some push constants in one command buffer and then you do a probe you're going to have to set them again when you start drawing again because it's going to forget them. I saw you said that you use Python script to load this data for Vulcan runner. Are you going to support something like memory mapping for digital memory access? It's very important feature for those who want to use Vulcan runner as a domain provided to those customers. Are you going to support such a feature like digital memory access or memory mapping for loading buffer? I just mentioned here. I wonder whether you have such plan to support more quickly loading the data from storage into the memory or digital mapping. Do you mean the data for the script? So the question was can you load data into the script? Yes, but would support some feature like GPU directly access loss memory in normal memory with load in water coping to the GPU buffer again. At the moment with the API you can give it the whole script. That's all you can do and obviously the buffer if you had any buffer data that would be an ASCII and then it would need to be a conversion process to convert that into memory somewhere. So if you want to give it some data in a memory mapped buffer that doesn't have support for that. We can pre-compare some binary data which will copy from some game. That's it. So you don't need to convert it into the GPU format anymore and there's no... In the inventor device the GPU and the CPU use the same memory. They don't have a separate memory. So I think if you had a test which needed to have a really large input then that would be a really good idea. Just add something to the API so you can say... A great API would support it. There is no limit in the API for that. Okay, so something in the script to say maybe... I just want to ask whether you have been considered if you have not seen it. I haven't considered it, but I think that would be a good idea. But I think for the moment, all the tests that we've encountered so far they haven't used a lot of input data so far. It's just everything's contained in the script. I just want to suggest either include priority test for the weekend run. Okay. It's an important factor. Yeah, yeah. Okay, thank you.