Closed anarsoul closed 6 years ago
So I got pp uniforms working. Things I figured out today:
1) render->uniform_address is address to a pointer to uniforms, not a direct pointer to uniforms. I'm not sure why double indirection is used here though. 2) uniforms are stored in fp16 format
I'll clean up code tonight and then I'll send a pull request.
That's great! As for the two points: I guess render->uniform_address should point to a per uniform descriptor array which contains each uniform's address and meta info. Maybe the meta info can be used to specify the size of each components (fp16 or fp32). If this can't be find in lima-ng, we have to do reverse engineering by the mali-syscall-tracker tool.
I couldn't find it in lima-ng. Looks like they always use fp16 for pp uniforms, see symbol_attach_data() in limare.c
And there's another issue - I'm not sure if it's with uniform fetch or with compiler itself. Basically, this shader doesn't work:
precision mediump float;
varying vec4 vVaryingColor;
varying float diff;
uniform float diffTest;
uniform vec4 uAnotherColor;
void main()
{
gl_FragColor = vec4(diff * diffTest * uAnotherColor.rgba);
}
It always works as if diffTest = 1.0 no matter what value is.
Looks like it's not related to uniforms. If I do 'gl_FragColor = vec4(diffTest * uAnotherColor.rgba);' it works as expected
I believe it's some compiler issue.
Feel free to play with https://github.com/anarsoul/mesa-lima/commits/lima-17.2-pp-uniform and https://github.com/anarsoul/kmscube
My kmscube fork has '-M uniform' and '-f floatval' options. First one make kmscube to use uniforms in fragment shader to pass color, second option is the value of 2nd uniform (diffTest in shader above)
You may run with LIMA_SHADER_DEBUG=pp ./kmscube xxx to see the fragment shader compiler process and result.
I'm afraid I don't know how to interpret its output:
https://gist.github.com/anarsoul/342a75689b4ab310acd1da2135c0fa57
But I'll try to dig into it tomorrow.
I give it a check by hand, seems OK. Maybe the other part has problem with varying setup or GP output. Another debug method is LIMA_DUMP_COMMAND_STREAM=1 to print the command stream especially the varying result after GP output. It can be also compared to maili-syscall-tracker output.
I believe something's wrong with scalar multiplication, i.e. in my case diff * diffTest returns diff, not multiplication result
Yeah, ppir_codegen_encode_scl_mul() is not implemented yet.
I implemented it and now it works fine.
Oh, you're right. I forgot to implement scalar mul/add after enable the scheduler to put node into it.
Merged in #11
From: https://github.com/yuq/linux-lima/issues/5
There're two reference for this topic:
lima-ng: https://github.com/limadriver-ng/lima the reverse engineering tool: https://github.com/yuq/mali-syscall-tracker 1 can be used directly for the command stream setup for the PP uniform; 2 can be used to dump close source driver command stream setup.
For mesa-lima work:
lima_draw_vbo() handle the PIPE_SHADER_FRAGMENT const_buffer update set uniform buffer address in lima_pack_render_state() the PP compiler may have some bug with uniform (not tested before)