Re: R,G,B,A : float possible ?

Ok,

Everything is still pretty much the same... only thing which needed to be
changed... is byte colors to floating point colors...

So
Red := X/(Width-1);
Green := Y/(Height-1);

^ Gives nice shading to test.

One thing which I didn't like was to convert it back to bytes again to
compare input and output... so I am not sure if I am going to like these
floating points...

But then again this could be a shader issue...

For now the colors have nothing to do with the shader issue...

The shader issue is with texture coordinates having to be from 0 to 1

The colors themselfes are now 0 to 1 as well.

So this more or less introduces a small new little problem:

Texture coordinates are ****ed.

Colors/output would be ****ed too ?!?

Actually the opengl on the screen is ofcourse in bytes... but what if it was
rendered to a texture ?

I guess it depends on the texture settings being used for the "render to
texture" ?

I wonder if the gpu can be exploited to do the "rounding for us"... in case
I need to use the byte/integer values in cpu...

That could save the cpu from having to do the rounding which would be good.

For my purposes I would need to be able to somehow stuff/shift bits into
these output colors... and they would need to turn into bytes/integers on
cpu side... or texture side...

But then again... for multiple rounds ofcourse not... because the textures
would have to function as input as well...

So input = output...

Now the question becomes do I really have to work with little tiny ****ing
values like 0.000012323 and 0.9345354.

Or can I work nicely with large meaningfull easy to understand values ? like
100 and 200.

In theory I think it should be possible but not sure...

Ultimately it probably doesn't matter because I could probably invent some
formula's to convert from bitfields into floating points fields and back
again...

However cpu and gpu could have little intricacies with floating point format
which might make it a bit tricky...

The shader itself could use these formula's as well to extract bit fields
from the inputs... do it's thing/processing... and compact the results back
into the floating point fields.

However for debugging purposes large floating point values would be much
nicer... also this makes experimentation/tweaking of variables easier.

Also the processing would be more efficient... if I didn't have to convert
all the time.

I am not sure about that but I would assume so...

However maybe the gpu has enough processing power... maybe it will be mostly
bandwidth limited and then these multiplications and divisions don't play a
around... but I just hate wasting resources like that you know ?!

It might also make the gpu unnecessarily warmer ?!

For now I will keep searching for better alternatives.

Bye,
Skybuck.

However I do need to stuff a lot of data/bits into the gpu per cell...

So having 4 fields of each 32 bits could be very nice !

That's 128 bits...

I need at least 6 * 8 bits = 48 bits.

Which I can rely on...

Extra bits are welcome though... especialy for another texture...

Would be very impressive if I can collect a lot of statistics per cell and
that could become a reality... however that's not my main objective for now
!

Actually maybe the 16 bit option is possible after all let's see:

4x16 = 64 bits.

That leaves 26 bits for floating point garbage/inprecision/fractions ?

Unfortunately I don't understand the floating point format so I do not know
what is possible.

This is a major weakness in my knowledge ?!

Maybe I should read up on that first before diving into gpgpu stuff which
seems to use lot's of floating points...

However there might also be an integer option which would make things much
easier for me...

Unfortunately the gpgpu tutorial/benchmark does not show this possiblity
which sucks pretty hard

I would be a bit worried that using integers inside the shader might reduce
performance... a benchmark could confirm or deny this or might be
inconclusive however I would still like to see a benchmark for int's.

So me gotta look into ints as well...

Lot's of stuff to do !

Bye,
Skybuck.

Ok,

Maybe it's time to try and use updated opengl 3.0 documentation...

I did find this doc/picture:

http://www.khronos.org/files/opengl-...rence-card.pdf

It mentions a little bit about the floating point format 16 bit and such...

Mantissa etc...

It also mentions int support an it mentions implicit conversions...

I just tried "shifting a float point variable" inside fx composer 2.5 like
so:

vTexel.X << 3;

It said something like can't do that must be integral etc...

The question is what I would be able to convert from floating point to int
myself more efficiently ?

For example only convert when absolutely necessary ? For example only on
input and on output...

I need more information about how a shader will perform when everything is
int... and there is lot's of code using ints...

Actually I just had an idea... I could still use the int type to do the
conversion for me !

// input, typecast float to int.
Int = Floating point input;

// extract bits from int
Floating point fields = Extract bits from int + shifts etc.

// work with floating point fields assuming it would be faster
Work with floating point fields
"if statements etc"

// output ints.
// compact bits back into int
int = typecast(Working floating points) + shifts etc.

Remaining questions are:

1. What is overal int performance...

2. Would keep the ints compacted as much as possible be better for
performance for example bandwidth wise inside gpu itself.

3. Can pixel shaders output ints.

Assumptions made:

bits inside floats would all stay valid <- dangerous assumption.

Extra precautions: made use mantissa fields only ?

Or maybe all bits will be maintained me not sure.

Could be a very interesting test just to shove floats into the textures...
"typecasted from integers to float"...

The stuff them through the gpu... do some non processing... just typecasting
back and forth...

and then get them out of it again and typecast the floats back to ints or
so... just to see if all bits are preserved or not...

I already read about slight floating point format issue's... not sure if
that goes into affect is bits are just stuffed into gpu and extracted
again...

It's starting to seem that a major test program is a necessity to answer all
of these questions....

That gonna eat into my time big time !

I could also try to wing it ! and use the gpgpu tutorial code to try and
code something up... but it could get nasty/difficult... or maybe not... but
I would prefer to try and write the code myself... but first I wanna get rid
of these texture coordinates... it annoying me... 0..1...

Or maybe I should just say **** it... and use what I have now... and go with
that for now ?!

But then I run the risk of writing all my code in a shitty way maybe...
speed wise

That's a real danger. I truely want maximum speed so I must know for sure.

So the first thing I am gonna do is **** the gpgpu tutorial and shove some
ints into it !

Bye,
Skybuck =D

Ok,

Here is a better document explaining/mentioning the internal format types...
the other arb document didn't contain any...:

http://oss.sgi.com/projects/ogl-samp...ture_float.txt

^ Also mentions the floating point texture concept...

So could be good document to read for some further information...

Seems a bit old but still relevant doc !

Bye,
Skybuck.

Ok,

I shuffed the mtf ints into the gpgpu tutorial:

I did two runs while fx composer 2.5 was slightly running as well:

First run ( 32 bit ints are at the bottom):

program started
TEXRECT - float_ARB - RGBA - 32
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 3615
ReleaseDC successfull.
program finished

program started
TEXRECT - float_ARB - RGBA - 16
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 7154
ReleaseDC successfull.
program finished

program started
tex2D - float_ARB - RGBA - 32
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 3613
ReleaseDC successfull.
program finished

program started
tex2D - float_ARB - RGBA - 16
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 7190
ReleaseDC successfull.
program finished

program started
tex2D - float_ARB - RGBA - 32 - ints
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 3477
ReleaseDC successfull.
program finished

Second run:

program started
TEXRECT - float_ARB - RGBA - 32
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 3608
ReleaseDC successfull.
program finished
program started
TEXRECT - float_ARB - RGBA - 16
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 7186
ReleaseDC successfull.
program finished
program started
tex2D - float_ARB - RGBA - 32
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 3613
ReleaseDC successfull.
program finished
program started
tex2D - float_ARB - RGBA - 16
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 7200
ReleaseDC successfull.
program finished
program started
tex2D - float_ARB - RGBA - 32 - ints
, N=16000000, numIter=200
CreateDC successfull.
CreateRenderingContext successfull.
MFLOP/s for N=16000000: 3483
ReleaseDC successfull.
program finished

The ints version does seem to be a bit slower... could be because of the
conversion... could also be because of possible overflows or so... not sure
about that.

But it doesn't seem to be too bad...

Here is example code which did work:

twod_arb_rgba_32_ints.name := 'tex2D - float_ARB - RGBA - 32 - ints';
twod_arb_rgba_32_ints.texTarget := GL_TEXTURE_2D;
twod_arb_rgba_32_ints.texInternalFormat := GL_RGBA32F_ARB;
twod_arb_rgba_32_ints.texFormat := GL_RGBA;
twod_arb_rgba_32_ints.shader_source :=
'int4 saxpy (' +
'in float2 coords: TEXCOORD0, ' +
'uniform sampler2D textureY, ' +
'uniform sampler2D textureX, ' +
'uniform int alpha ) : COLOR { ' +
'int4 y = tex2D (textureY, coords); ' +
'int4 x = tex2D (textureX, coords); ' +
'return y+alpha*x; }';

Apperently it's as easy as simple replacing the floats with ints...

However there might be only little problem... tex2D still expects floats ?!

So had to leave the "in" in float2...

Could be an indication that texture coordinates must be in 0..1 or always
are inside the shader ?

Me not sure about that.

All the other shader code looks similiar though... none of them do anything
to the texture coordinates...

Yet some are normalized and some are not... making me believe that
unnormalized text coordinates should somehow be possible ?!

Hmm...

Bye,
Skybuck.

This document might come in handy too some day:

http://www.flipcode.com/archives/internaltable.html

It's probably a bit old but could still be handy..

Gonna save it just in case !

(Could be handy for "optimizations")

Bye,
Skybuck =D