@kvark what does
storage+2-gl::FLOAT_VEC2 do?
@bjz it's the number at the end of the definition: FLOAT_VEC? (2,3,4)
which is the number of components that we extract from it
ok, bbl
If every string in the pipeline that is the same always points to the same memory address, we can avoid the cache miss in the case for a string compare. Pointer A == Pointer B, no point in comparing their content.
This is also 8 bytes, vs 24 that @kvark has proposed.
like, once you commit to building them, you can't alter them?
oh, btw - tried an oculus rift today - not with Rust, just the bundled demo.... <3 <3 awesome
it was interesting watching people use cgmath today -_-
Good, bad, reactions?
yeah, just some confusion
traits and stuff
I think it might be better to re-export things at the top level
@csherratt sure, we can match the input-outputs and store just indices, but this caching spawns more questions than it solves
That's half-truth. In fact, we don't want (of course) to match these strings at runtime, even if the comparison cost is low, because we'd still need to walk those mesh attributes for each shader attribute. instead, we just need to have that target index baked in somewhere. Perhaps, a single HashMap<(ProgramHandle,MeshHandle), IndexSequence> will suffice.
kvark @kvark is off for today
@csherratt ^