Mac OS X 64-bit graphics support

[RafSchietekat]

On a current Intel x86-64 Apple Macintosh (my first use of TBB with OS X on this configuration), with TBB 4.1 update 2 (unpack source distribution, make examples), example graphics were conspicuously absent. The remedy is to disable/remove tbb41_20130116oss/examples/Makefile:113-119 ("# GUI for examples does not support 64-bit platforms" etc.): graphics will now be visible, but upside down.

Is opposite vertical orientation the only reason for deliberately disabling graphics support? That seems a bit harsh...

[Vladimir_P_1234567890]

Hello Raf,

The support was not  deliberately disabled but accidentally not enabled in this particular makefile during port from carbon to cocoa.
Use makefiles from example folder i.e. ../examples/parallel_for/seismic/Makefile or XCode. Or remove the line:).

Regarding 'upside down picture' we are looking why this was happened.
--Vladimir

[RafSchietekat]

I disabled examples/Makefile:113-119 (as indicated above). I don't immediately see what (else?) you mean by "Use makefiles from example folder i.e. ../examples/parallel_for/seismic/Makefile or XCode. Or remove the line:).", because the seismic example was visible without any correction to the file you mention (although only for an instant, so maybe it should be made to show a longer time interval or so).

For the vertical orientation, I presume that drawing_area is supposed to represent the pixels from left to right and then from top to bottom (not documented of course...)? That has to be flipped upside down for use with OpenGL (which assumes bottom to top), perhaps using glPixelZoom(1,-1) (with the appropriate raster-position corrections of course).

[RafSchietekat]

Correction sent through http://threadingbuildingblocks.org/submit-contribution.

[Vladimir_P_1234567890]

released in update 3

--Vladimir

[RafSchietekat]

Confirmed, thanks!

Perhaps you could make the "seismic" example run for a fixed amount of time, though? It used to take several seconds on my previous computer, it progresses (assumedly) at glacial speed when running from a remote X client (even slower than pover, which speeds past it like a snail), but on my current computer I would literally miss it if I were to blink at the wrong time. On the upside, this is the first time I've noticed that it actually does something interesting if I click on the window (after I adapted Makefile to make it run longer)...

[Vladimir_P_1234567890]

it is controlled by "fixed amount of frames" that can be overriden via command line, $(ARGS) parameter. By default this is 300 frames if it is run via makefile and 1000 frames in case it is run from xcode (without command line).

[RafSchietekat]

That's what I did. Could polygon_overlay and seismic be making a round trip per pixel, as opposed to an entire rectangle for tachyon etc.? Just a side issue, of course, but while we're on the subject...

(Added 2013-05-13) The side issue was about slowness on X across a network with significant latency.

[RafSchietekat]

What happened in developer release tbb41_20130425oss compared to release 4.1 update 3? Now I don't see seismic even if I don't blink, and the parallel tachyon examples seem to appear fully computed (way superscalar)!

(Added) Sorry, I should have tried 4.1 update 3 again before posting this, because it shows the same changes, although I don't see how (surely that Thunderbolt-related update didn't cause this?). The superscalar thing is quite disconcerting: maybe there's a delay in bringing up the windows that takes more of a bite out of the shorter times, and perhaps the computation is also faster before the window is shown? Anyway, seismic and tachyon are clearly not enough of a challenge anymore on recent hardware, so at least seismic should run for a specific or unlimited time instead of an arbitrary number of frames (increasing that would be too much for slower machines), because otherwise you'll never be able to see what happens when you click on the window...

[Vladimir_P_1234567890]

this is OS X, right? It looks that [self setNeedsDisplay:YES] does not work somehow. Maybe because cocoa_update variable was cached in this case since it is  not volatile.

[RafSchietekat]

Oddly enough I can't reproduce the problem anymore (so I also can't test your hypothesis), but please go ahead and make cocoa_update atomic if that seems appropriate (don't use volatile). I don't really understand the protocol (if cocoa_update communicates between threads, shouldn't it then be more like an epoch instead?), but it also doesn't really matter (so I didn't look very carefully).