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