[Bug] mat3x3 UBO incorrect shader index access

[mcost45]

Description

In the midst of updating to v9 Deck, I found mat3 uniforms seem to behave incorrectly (within a UBO).

Previously, a mat3x3[1][1] index would access its 'centre' value. But now it seems to point to mat3x3[1][2] instead?

Flavors

• Script tag
• React
• Python/Jupyter notebook
• MapboxOverlay
• GoogleMapsOverlay
• CartoLayer
• ArcGIS

Expected Behavior

mat3x3[1][1] access points to 'centre' value

Steps to Reproduce

Repro here: https://codepen.io/mttrx/pen/ZEgmWWK

• Colour is expected to be black (-> [1][1]), but instead it is red (-> [1][2])

Environment

• Framework version: [email protected] ([email protected])
• Browser: Chrome 130.0.6723.117
• OS: Windows 11 Pro 10.0.22631 Build 22631

Logs

No response

[ibgreen]

• I suspect that you are hitting some tricky layout rules for uniform buffers.
• I believe that each row in the matrix needs to be aligned to a 4 element boundary adding an unused value in each row.

[11, 12, 13, X, 
 21, 22, 23, X,  
 21, 22, 23, X]

• though this may not be the full explanation. I would expect the shift be in the opposite direction.
• FWIW, these pesky alignment issues should go away if you use 2x2 or 4x4 matrices

[mcost45]

Thank you for your help, and interesting! The issue doesn't occur with a 4x4 matrix.

I think some extra information about odd UBO behaviours and tricky types (to avoid?) like mat3 would be a very useful addition to the deck.gl/luma.gl upgrade guide/docs.

Somewhat unrelated, I also ran into the incorrect uniform order issue, then only later found the GPU Uniforms docs which mentions this behaviour. With this knowledge, the order requirement makes sense. But from an API/naive perspective - when defining an object (uniformTypes) instead of an array, generally I would assume that the order of properties does not matter. I also would have found this information very useful if it was included in the upgrade guide 😆