Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
memory layout
maddanio
Unregistered

 
Post: #1
memory layout
hmm, ok. i need to know how structs are layout in memory. i have a struct effectively like this:

struct vec3f{
float v[3];
}

and some methods with it (quite a bit actually). so now i would like to know what something like this:

vec3f[100]

looks like in memory.

will it be 300 floats (which would be perfect, then i can just shove the lot to vertex arrays even using client storage and such while realtime transformig...u get the point).

or will it be 100 pointers to 3 floats each.

or will there even be a kinda structure identifier with each struct to point to the methods or something?
2003.03.17 08:53 AM
Quote this message in a reply
wadesworld Offline
Member
***

Posts: 187
Joined: Mar 2005
Post: #2
memory layout
I believe that would be laid out as 300 floats.

Best thing to do is run a simple test though - setup a small test structure and look at it in memory.

Wade
2003.03.17 11:36 AM
Find all posts by this user Quote this message in a reply
Mark Levin
Unregistered

 
Post: #3
memory layout
I think it would be laid out as 100 pointers to 3 floats each, but, yeah, try experimenting with it.

Also, compilers are allowed to pad structures for better alignment, so you may not be able to just treat it as an array of float pointers either (you'd have to find the size of the structure and use that as the step value when going through it).
2003.03.17 01:06 PM
Quote this message in a reply
DoG Offline
Moderator
*****

Posts: 400
Joined: Mar 2005
Post: #4
memory layout
it would definitely be layed out as float[300], I believe. Floats are aligned on a 32bit boundary, only, I have not seen anything in the gcc docs that would say otherwise.

Though, if you already do that, I would make vec4f structure, since OpenGL uses homogenous vectors anyhow, and I believe a chacheline is bigger than 128bit anyhow, so that it takes the same time to read as vec3f, but you are wasting less space in the cache (or get added functionality for your 4th coordinate). Also, incorporating altivec into the program would be easier.

DON'T PANIC
2003.03.17 02:26 PM
Visit this user's website Find all posts by this user Quote this message in a reply
maddanio
Unregistered

 
Post: #5
memory layout
ok, ill try later tonight and report back. yah, i thought of the 4f too. but it will be late then Smile. so maybe i add that the struct is actually a class and there is inheritance going on (though no virtual stuff, so shouldnt expect a vtable around...). still expect float[300]? (or 400 once thats updated...) would be really cool, then i can index call them all which fits nicely with the OBJ format. and explosion Smile...

ah, btw had this altivec thread going on applegl:

altivec will want to do massive parallel operations on aligned vectors. so its hard to teach it xyzwxyzw thats the impression i got. but a stride of 4 might actually work, its a power of two....dont think i will sleep tonight Smile.

thniking about 3d fourier...
2003.03.17 02:35 PM
Quote this message in a reply
maddanio
Unregistered

 
Post: #6
memory layout
there is an interesting question at that point: when importing OBJ for example, should one use vertex lookup or dump the whole resulting vertex stream? the latter would thatn translate into vertex_range calls and also allow stuff like explosion along the fragment normal (which lookup wouldnt as it guarantees connectivity preserve).
2003.03.17 02:39 PM
Quote this message in a reply
NCarter Offline
Moderator
*****

Posts: 270
Joined: Feb 2005
Post: #7
memory layout
Quote:Originally posted by maddanio
or will there even be a kinda structure identifier with each struct to point to the methods or something?

Are you using C++? If so, and your struct (class) contains any virtual methods, there will also be a hidden vtable pointer somewhere. If you want to make sure the data is laid out in a predicable way, you shouldn't use virtual methods with this struct.

Neil Carter
Nether - Mac games and comic art
2003.03.17 03:00 PM
Visit this user's website Find all posts by this user Quote this message in a reply
maddanio
Unregistered

 
Post: #8
memory layout
i dont (mentioned it somewhere above). so no virtual functions means no additional stuff in the class than the data members?
2003.03.17 03:29 PM
Quote this message in a reply
OneSadCookie Offline
Genius Bar
*****

Posts: 2,154
Joined: Feb 2005
Post: #9
memory layout
Code:
struct vec3f
{
    float v[3];
};

vec3f array[100]

will come out as if it were float[300]. This will be unncessarily slow; much better is

Code:
struct vec3f
{
    float v[3];
#if defined(__cplusplus)
private:
#endif
    float dummy;
};

As long as you have no virtual functions in your class, it will be laid out like the C struct with the same fields. Note however that

Code:
struct Foo
{
    double x;
    float y;
};

struct Bar
{
    int x;
    char y;
};

sizeof(struct Foo) == 16
sizeof(struct Bar) == 8

(In the usual case with a 32-bit PowerPC compiler), so you've got to be pretty careful in general when dealing with this stuff.

Certainly, always use sizeof() to calculate the stride you pass to OpenGL, and never read directly from a file into a struct.
2003.03.17 03:46 PM
Visit this user's website Find all posts by this user Quote this message in a reply
maddanio
Unregistered

 
Post: #10
memory layout
so that puts me on the safe side if i use

struct vec4f {
GLfloat v[4];
void fun() {...}
void ction() {...}
}

struct model {
vec4f points[100];
int indices[400];
}

or similar?
2003.03.17 04:01 PM
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)