Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to generate working shaders #32

Open
DoktorJ0nes opened this issue Nov 21, 2023 · 1 comment
Open

Unable to generate working shaders #32

DoktorJ0nes opened this issue Nov 21, 2023 · 1 comment

Comments

@DoktorJ0nes
Copy link

DoktorJ0nes commented Nov 21, 2023

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:

  • Build an OpenGL application and insert the GLSL shader I want to use there. Dump the shader with help of Mesa.
  • Copy the 64bit asm hex code to the shaders,h of QPUassembler, change the used shader there and build the QPUassembler application
  • run the QPUassembler application, copy the generated asm code as a shader into my vulkan projects code.
  • edit the mapping of the vertex shader uniforms accordingly.

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!

@DoktorJ0nes
Copy link
Author

DoktorJ0nes commented Nov 24, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant