As an update to this older topic: recently some review/benchmarking websites started using FRAPS to measure latencies and jitter on a per-frame basis.
They found that AMD struggled with jitter a lot more than Intel and nVidia. nVidia explained that roughly since the introduction of Fermi, they have been doing some smart queue management/scheduling to minimize jitter. It is quite possible that the above bug was a result of their scheduling getting confused from all those render threads in a single application. And it would explain why the two ATi-powered systems were not affected, as ATi was not doing any kind of management at all.
It would also explain why nVidia took the issue seriously and was able to locate and fix the bug so quickly.

For more info, see my blog, and follow the links: http://scalibq.wordpress.com/2013/03/27/latency-and-stuttering-with-3d-acceleration/
Posted on 2013-04-08 07:30:11 by Scali
And I think ignoring PowerPC isn't a big deal either. Don't think many people still use those.


Well... I have come into two Apple Mac Mini G4 boxes. So I am now using PowerPC Macs.
I'm trying to set them up for development. Retracing my steps here, to see how far I can get with compiling the code on those machines.
They are currently running OS X 10.4.11, but I hope to upgrade them to 10.5 as soon as I can get my hands on the proper installation media.
Posted on 2013-05-13 10:11:01 by Scali
Well, the code can compile on the machine... but it doesn't work, because I never bothered to add support for Big Endian to the BHM file routines.
Funny enough it has worked fine so far, even on ARM. ARM was originally Little Endian, but since v3 they can run in both modes (as can PowerPC). Apparently it is being run in Little Endian mode for Android at least. I never even gave it a thought, I had totally forgotten that I never handled endianness in BHM, it's been so long ago.

Anyway, no time like the present to right that wrong.
Posted on 2013-05-14 04:09:57 by Scali
Right, upgraded one machine to 10.5. Doing the other now.
Also managed to fix all Big Endian issues in my BHM code, and enough OpenGL issues to run on the rather outdated Radeon 9200 chip and its rather outdated OpenGL drivers.
Fun stuff. Will clean the code up a bit, and then update the SourceForge repository with the new Big Endian fixes.
Posted on 2013-05-14 17:00:25 by Scali
Okay, new Endian-handling code is now in the SourceForge repository.
Also fixed a few minor bugs that magically never got triggered anyway in BHMReader.cpp :)
Posted on 2013-05-17 09:59:39 by Scali
I've also ported some of the stuff of my more 'full-featured' OpenGL codebase to the Mac.
The BHM3DSample is only a minimal example.
The full OpenGL codebase also supports things like render-to-texture and streaming video.

So far that stuff was Windows-only, but I did have QuickTime support in Windows.
So I figured I should bring QuickTime back where it belongs: on the Mac.
I have backported the streaming video stuff with OpenGL's PBO's to the rather dated OpenGL implementation on my Mac Mini G4 (also had to handle lack of non-power-of-2 textures, that's a first :)).
And I ported the QuickTime code to work on OS X. Which was not as simple as I had hoped. The Windows version turned out to be quite different in some areas, and it took quite some work to get things working on a Mac.

But it works, and the performance is not all that bad: http://youtu.be/eSLqAUyoCDk

Next step will be to interface the webcam through QuickTime, and stream that onto a texture. Eventually this side-project will give me most of the functionality that our Windows application has. Porting to linux/FreeBSD should not be that big of a step from there, since a lot of the OS X code is already POSIX and OpenGL. I would mainly need to write replacements for the QuickTime code.
Posted on 2013-06-07 19:31:23 by Scali