[epiar-devel] CodingConventionProposal Updated, Still in Proposal

[Chris Walton]

> Do compilers generate faster code with "doubles" rather than "floats", I
> think I've heard this somewhere, but I'm not sure?  And does OpenGL have
> speed differences between using either?  I also saw a benchmark where the
> use of unsigned binary was faster than float, but I don't know why that
> is.  These questions are probably minutia that doesn't really matter.
>


That's very compiler and CPU specific, but in most cases,

(1) floats are faster than doubles. Most modern CPUs will handle them
internally with the same number of clock cycles (in fact, the x86 always
handles any floating point number internally in the same 80-bit precision
regardless if you use them as double or float). However, floats require 4
bytes vs. 8 bytes for double, so you can pack more of them in a cache line
and it takes less time to read them in from memory and/or hard disk.

(2) Regarding OpenGL, I'm not 100% sure, but my 99% intuition says - see
(1).

(3) With "unsigned binary", you probably meant one of two things. Either you
meant byte values for RGBA (0-255 instead of 0.0f-1.0f), or you meant fixed
point integer instead of floats. Either way, if there is a difference, it's
very very minute, and it depends entirely on the interface between the
driver and the actual hardware. Modern hardware will likely accept floats
directly, older hardware will probably take fixed point integers. We're
dealing with too high an abstraction layer that it'd be worth worrying much
about.


> I'm still going through the OpenGL book, but I would like to get your
> ideas on the best way to optimize the OpenGL code.  Right now I see:
> 1) Immediate mode is deprecated in OpenGL 3.0, we might want to switch to
> VBO's to be future compatible, but the benefits of this dubious at best
> for now (low priority), I think VBO's would also require an overhaul of
> the way things are rendered.
>

Using VBOs shouldn't require much overhaul, and yes, it is an improvement.
We should probably have one common quad VBO, since most things are just a
quad that is rendered. The vertex buffer would be a triangle strip, with UVs
and coordinates of 0.0f in the top left corner and 1.0f in the bottom right
corner. Then, beforehand, you just need to set the model/object matrix
(whatever it's called in openGL :)), the texture, and off you go. I believe
we actually have a generic DrawImage() function, that could just be changed
and it'd affect the whole system.

We're not doing anything fancy such as rendering to texture, so
transitioning from immediate to non-immediate shouldn't disrupt anything at
all. :)


> 3) Culling, I don't know much about this right now, but I plan on looking
> into it more.
>

Matt's quad tree code already does that (as Chris said). It works well
already, and once the attached objects can move up/down the hierarchy, it'll
work perfectly.


> 4) Code cleanup (E.G. redundant OpenGL calls, turn off unnecessary
> features)
>

There are probably few redundant openGL calls at the moment. Besides, most
drivers will actually filter out unnecessary state changes.

Regarding openGL speed, I'm certain we're not bound by draw-calls
themselves, since we have relatively little of those and all of those are
quite cheap, or simple renderstate changes, since we have very few of those
as well, but by texture uploading and texture setting. There's a neat, easy,
and flexible way of sorting our draw calls on the CPU so that the GPU gets
very few state changes. If anybody feels like working on that, let me know
and I'll fill you in. (I'd do it myself eventually, but as you know, I don't
have too much time on my hands :))

-- Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://epiar.net/pipermail/epiar-devel/attachments/20091227/92db3589/attachment.html