On Tuesday, March 29, 2016 at 11:37:25 PM UTC-7, Laurent Moussault wrote:

But if that is the case then defining the serialization function,
f32.Bytes, in the first place doesn't really much sense, does it?
The function might be useful to load assets from the disk, but that would
probably be done with a more specialized format.

Related to this point, one thing I haven't had a definitive answer for in
my own mind is whether [16]float32 is guaranteed to contain the same bytes
as [16]C.float. Naively I would say, "yes they are the same," but from what
I've read elsewhere I'm actually not sure that is guaranteed.
I don't think there's any guarantee, but then again, the situation is
similar in the C world (relative to the GPU, e.g. for uniform buffers). The
only difference is that most compilers provide a way to customize the way
structs are packed. I think that for low-level programming, you can't avoid
making some assumptions on your compiler.

In regards to multiplication order, yes, because Transpose(A * B) ==
Transpose(B) * Transpose(A) you can do work on column-major matrices using
row-major algorithms. But actually recommending that people transpose all
their matrices and reverse their matrix multiplication sounds quite
sadistic to me, truly. I really do think column-major should be used, even
if [4][4]float32 is truly the desired type signature. It sounds like we
mostly agree there, though.
Yes, column-major is now the recommended way, if only because it makes it
easier to use material from math papers. But it wasn't always like this (I
think the first few books on graphics programming were using row-vectors),
and the fact that GPUs registers are 4 floats wide means that with
row-major storage you can send affine matrices with only 3 fully used
registers, whereas with column-major you need 4 under-used registers. It
only matters if you have a lot of affine transforms to pass to the GPU
(such as in skeletal animation).
Thanks for filling in that bit about GPU registers. I still haven't gotten
to a point where I need to use non-square matrices.

But if using a [4][4]float matrix with column-major order things are
somewhat confusing because matrix literals will look like they are being
defined in row-major when they are not.
The thing is, this is exactly what GLSL does (as well as swapping the
indices relative to the mathematical norm). And in the end, this is
programming, not mathematics. When doing graphics coding, you end up
writing shaders in parallel to Go/C code; having the same notation (or as
close as possible) in both is IMHO a must.
That is a valid point. Indeed the first time I saw a matrix being
constructed from vectors in OpenGL I wasn't positive which way they were
being oriented. Matching those semantics would make things more intuitive.

On this topic, I'm not too sure about the way matrix operations are exposed
in golang.org/x/mobile/exp/f32. Mutating the receiver is currently the
fastest method, but if my benchmarks are correct, returning the result by
value is only slightly slower (28 ns/op vs 24 ns on my machine), and much
more convenient. I'm not sure how the compiler currently handle this, but
my guess is that something similar to C++ move semantic is happening. In
fact, passing the argument by value doesn't seem to impact performance
either. I think that "M = M.Times(N)" is easier to read than "M.Mul(M, N)".
I wouldn't have expected the difference to be so small. I will poke around
in that area to investigate as well. Although honestly I was trying to
deliberately avoid discussion of the API functions/methods when I sent my
my initial message. I think the API does need work. But I thought that
solving the impedance mismatch between the package types and OpenGL was a
more critical problem to solve.

You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 17 | next ›
Discussion Overview
groupgolang-dev @
postedMar 29, '16 at 3:30p
activeMar 31, '16 at 12:58p



site design / logo © 2021 Grokbase