[gameprogrammer] Re: Fixed point vs floating point in modern computers

  • From: Bob Pendleton <bob@xxxxxxxxxxxxx>
  • To: gameprogrammer@xxxxxxxxxxxxx
  • Date: Mon, 27 Feb 2012 00:11:23 -0600

Another thing to consider is using fractional arithmetic instead of
fixed point. It is used all over computer graphics, but most people
don't even know it. For example: The way colors are represented as 3
values in the range 0 to 255. Or 0 to 65535. Or alpha as 0 to 255. The
color cube is defined for the range 0 to 1.0 and alpha has a range of
0 to 1.0. These value are, of course, the numerators of fractions
where the denominator is 255. So a color value of 0 is really 0/255 =
0 and a value of 255 is really 255/255 = 1. We all know that, right?
The thing is that when you know what the denominator is, you don't
have to carry it around. You can just do integer arithmetic on the
numerators (as long as your remember the rules for multiplication and
division of fraction) and not have to deal with all the nastiness you
run into when writing fixed point code.

The nice thing about fractional arithmetic is that you can use
anything as the denominator, even powers of ten so you can represent
10ths or millionths if you want. And, you can have any number for a
numerator, so you can use a 32 bit signed int to represent billions of
17ths if you want. Whatever works for your computation.

The MMX instructions are SIMD integer instructions that could do this
kind of stuff really fast.

Bob Pendleton.



On Fri, Feb 24, 2012 at 1:46 PM, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote:
> I don't really want to make my code have the requirement of needing shaders
> at this point.
>
> As it currently stands, i can run it on any device / machine that can
> compile C++ and has a way for me to copy pixels to the display and find that
> really attractive since i have a lot of lateral mobility (while maintaining
> a single code base)
>
> Not quite sure all of what I want to do with it yet and that lateral
> mobility is really nice for me, and makes it easy to showcase the techniques
> i came up with.
>
> If i could use something like perhaps OpenCL and i could abstract it well
> enough such that the same code worked on CPU and GPU, i'd be interested in
> something like that, but i dont want to fork it or muddy the waters or limit
> my options just yet.
> 2012/2/24 Stéphane Marchesin <stephane.marchesin@xxxxxxxxx>
>>
>> On Fri, Feb 24, 2012 at 11:29, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote:
>> > "The trouble is that floating point implementations are a mess."
>> >
>> > That's what i'm hitting and it makes me sad hehe
>> >
>> > "1) be very careful about the stability of the numerical methods you
>> > use.
>> > That is the best way to avoid problems cause by variations in
>> > precision."
>> >
>> > Agreed... I've investigated a little into this but so far no luck on
>> > finding
>> > the problem.  I'm also making sure and be as "smart" as possible about
>> > the
>> > math.  For instance as the ray walks through my world grid, I don't
>> > check if
>> > the ray is between the beginning and end time (the time period of the
>> > ray
>> > being inside the cell), i check that it's less than the end time since
>> > if
>> > you are close enough to the edge of a cell, and use perhaps slightly
>> > different equations for the start and end, you could have different
>> > values
>> > and get into problems that way where an intersection fell between cells
>> > :P
>> >
>> > "So, maybe you should look at how to do all this in the GPU, rather that
>> > in
>> > the CPU."
>> >
>> > That would be really awesome.  I would love to do that, but for the
>> > google
>> > "Native Client" at least, they don't expose a way to do that which is
>> > kind
>> > of sad.  I think you are right though, it might be really awesome to
>> > make it
>> > able to run on the GPU with OpenCL or something just to see how much
>> > faster
>> > it is (hopefully WAY fast)
>>
>> Why can't you use GLES2 for that? It's definitely possible to do
>> raytracing in GLES2 with shaders, compute APIs are not required for
>> that (you don't need the thread synchronization stuff for raytracing).
>>
>> Stéphane
>>
>> ---------------------
>> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>>
>>
>



-- 
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email: Bob@xxxxxxxxxxxxx
+ web: www.TheGrumpyProgrammer.com

---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html


Other related posts: