02:30 imirkin: is it legal to not bind an attribute to a (vertex) shader input?
02:38 HdkR: imirkin: Yes, you'll then get default values which are defaulted to vec4(0, 0, 0, 1)
02:39 HdkR: I believe you can change that default value with the non-array attribute value functions? glVertexAttrib?
02:55 imirkin: HdkR: and then the million dollar question ... how does that come through gallium? :)
03:13 HdkR: imirkin: No idea :D
03:13 jekstrand: imirkin: Magic!
03:14 imirkin: basically i'm questioning the current handling of double-slot attribs
03:14 imirkin: since it's based on the list of vertex bindings
03:14 imirkin: and the list of shader inputs
03:14 imirkin: which might not be the same list.
03:15 imirkin: but perhaps the list of vertex elements is guaranteed to match what's in the shader, and then it's all fine
03:15 jekstrand: imirkin: It looks like iris will do 0, 0, 0, 1 if you give it PIPE_FORMAT_NONE
03:16 jekstrand: But I don't know if that's intentional behavior or not. It also wouldn't have correct int vs. float behavior
03:16 imirkin: also that relies on the element being there, i guess? i need to re-check how all that stuff works, it's a bit abstract in my memory
03:17 imirkin: for some reason it's a bit of gallium that never sticks -- i re-learn it every time i have to deal with some new and improved bug
03:17 imirkin: and then promptly re-forget
03:17 imirkin: time to do that again, i guess
10:09 mareko: imirkin: it's guaranteed to match the shader
10:10 mareko: imirkin: radeonsi rejects draw calls where num_inputs > num_velements
10:10 mareko: because we would hang otherwise
16:34 imirkin: mareko: ah ok, cool
16:35 imirkin: mareko: so on binding a new shader (e.g. one with explicit locations set), a new list of vertex elements is generated?