yuq / mesa-lima

Deprecated, new place: https://gitlab.freedesktop.org/lima
https://github.com/yuq/mesa-lima/wiki
165 stars 17 forks source link

Implement PP uniform support #7

Closed anarsoul closed 6 years ago

anarsoul commented 6 years ago

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)

anarsoul commented 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.

yuq commented 6 years ago

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.

anarsoul commented 6 years ago

I couldn't find it in lima-ng. Looks like they always use fp16 for pp uniforms, see symbol_attach_data() in limare.c

anarsoul commented 6 years ago

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.

anarsoul commented 6 years ago

Looks like it's not related to uniforms. If I do 'gl_FragColor = vec4(diffTest * uAnotherColor.rgba);' it works as expected

anarsoul commented 6 years ago

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)

yuq commented 6 years ago

You may run with LIMA_SHADER_DEBUG=pp ./kmscube xxx to see the fragment shader compiler process and result.

anarsoul commented 6 years ago

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.

yuq commented 6 years ago

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.

anarsoul commented 6 years ago

I believe something's wrong with scalar multiplication, i.e. in my case diff * diffTest returns diff, not multiplication result

anarsoul commented 6 years ago

Yeah, ppir_codegen_encode_scl_mul() is not implemented yet.

I implemented it and now it works fine.

yuq commented 6 years ago

Oh, you're right. I forgot to implement scalar mul/add after enable the scheduler to put node into it.

anarsoul commented 6 years ago

Merged in #11