[Gridflow-dev] ping (fwd)

[Tom Schouten]

On Thu, Sep 09, 2004 at 07:20:46AM -0400, Mathieu Bouchard wrote:
> 
> replying to: Tom Schouten <doelie at zzz.kotnet.org>
> > > > bitgrid/8/320/240/3
> > > > this describes a 8 bit, planar row encoded image: w=320 h=240 planes=3
> > > I'm not sure what you mean. Is it like char[3][240][320], or like another
> > > C array shape?
> 
> > > GridFlow 0.7 has two 32-bit types (i,f) and two 64-bit types (l,d). How
> > > would you differentiate between int and float in general? and signed vs
> > > unsigned?
> > i don't. i don't need generic grids yet, only to implement permutations
> > and have at least some raw bit representation.
> 
> Yes, but GridFlow needs to differentiate between them.
> 
> > my matrices are floating point, images are fixed point.
> 
> So would your converters consider that float==matrix and int==image, in
> both GF->PDP and PDP->GF ?
> 

hmm.. i don't know yet. maybe explicit casting is best.
just trying to fit everything together..


> > > Besides, GridFlow does not use planes at all, ever, unlike, say, Jitter.
> > what do you mean? the planes are just your outer dimension wrt to memory
> > layout, no? if that happens to be colour, you have planar data.
> 
> Well, that's a strange definition of planes.
>

but it catches the concept of plane in the context of a grid's memory
layout, no?
 
> Jitter has a concept of planes directly in its data model that corresponds
> exactly to the one of channels and that causes images to be only
> two-dimensional because the channels are considered not a real
> dimension. 

i don't see why you shouldn't/can't treat the planes as an extra dimension,
because looking at the data layout, they are actually..

> Besides, I've only ever heard of "planes" to mean something at
> the color channel level (see also: X11, EGA, etc).

indeed.


> > gcc 3, but use 3.3.1 or higher.
> 
> OK, I'll see if I can afford to make that move within the next years. I'm
> still using GCC 3.2.2 at home, and until I can upgrade all of my platforms
> to GCC >= 3.3.1, I'm not going to depend on that for performance.
> 
> > gcc 3 is really nice, but a lot of the optimization code seems buggy.
> 
> What kind of bugs are you thinking about?
>

i think i got some register allocation errors, and some other
'can't inline' warnings etc.. most of these have to do with the new,
agressive optimization code combined with vector extension. 
sometimes it just dies on valid code.