DoktorJ0nes
commented
1 year ago Okay so to answer my own Questions for future readers:
The "toolchain" I used was correct. But when you use a shader and you want to use attributes these attributes need to be declared as an uniform in the GLSL shader code. But the caviat is that the shader will load them in an wrong order at runtime on this vulkan driver. This means that you need to change this order manually in the assembly code of the shader. When doing this its important you keep my answer to question number a) in mind.
a) Normally the OpenGL and Vulkan Drivers for the Raspberry-Pi load the viewportX, viewportY, W and S attributes automatically in the shader. This driver doesnt do that automatically. So you need to provide that values to the shader. No need to declare an input attribute/uniform for that values in the GLSL shader tho.
b) Its not a compute shader but an Coordinate Shader that is automatically generated/compiled when you dump your GLSL shader via Mesa for example.
c) It doesnt really matter. Its just important that attributes and uniforms are loaded with the "uni" expression in the assembled shader. Attributes from the Vertex Buffer such as vertex positions will get loaded from vpm memory in the assembled shader code.
d) Nope the autor of this repository likely writes the shaders used in that project by himself without generating the assembly code from GLSL shaders.
e) I answered that above in this comment.
f) likely the order of the "uni" value loads in the assembled shader code. As I stated above that order can get messed up when generating code by dumping shaders from GLSL using the Mesa Driver.
g) nope. Just make sure that your memory mapping for the shader values are right and so on.
I am trying to get self written shaders to work for days now. Because we cant use SPRIV or compile GLSL for the driver I need to rely on your documentation about generating shaders. Unfortunately the provided documentation is very sparse. I tried to dig thru the code of the tests but without any luck. I tested all your test examples and they all seem to work.
What I am trying at the moment:
Unfortunately the shader just randomly lets some kind of geometry flicker sometimes on the screen.
I have a few questions: a) Why are you passing the viewport X and Y scale to the shader? I looked up all test examples and you are always doing this. Does it have a reason? b) Why are you using a compute shader in every test example? Even in the triangle test. You are also using the viewport scales there. c) What versions of GLSL are supported when doing the toolchain I described above. I am guessing you also somehow "compiled" your shaders and not written them by hand in asm. In the Quake3Arena source code I saw the GLSL version used there is 450. Unfortunately on the Pi we are restricted to version 120 with the Mesa driver and so cant dump GLSL shaders using any higher version. d) In the Quake3Arena project for your driver I saw some plain GLSL shaders. Is there a parser tool in the project which can be used to generate shaders for your driver? e) Is my toolchain described above correct? f) is there anything to change in the asm code manually? g) Are there any additional steps necessary to do to get a shader working?
I really love the driver and its speed. Your work on an own Vulkan driver is outstanding. But I am asking myself if people really use it when its so hard to get shaders working without a real documentation. I think when you are able to answer my questions people could really benefit.
Thank you!