Merge pull request #92 from kleinerm/master

Pull fix for OSX on Apple MacBookPro with Retina display.
Merge pull request #94 from kleinerm/master

Pull: Add support for NV-E0 GeForce-600 series "Kepler" gpu's.
Add comment about routine misnomer

Also implement a warning mechanism, so that someone using this routine
based on its name (without reading the
help text) is less likely to be led astray.

Warning text is on by default, but can be overridden with a new
optional argument.

DHB
Merge pull request #96 from kleinerm/master

Post-Release update for PTB BETA RELEASE "The fun in dysfunction"
Fix texture sharing on Windows nVidia systems
PsychImaging: Add support for xyY -> XYZ and XYZ->RGB color space conversion.

Add support for imaging pipeline implementation of the
SensorToPrimary() and xyYToXYZ() M-Functions.

This allows to draw into the framebuffer in xyY chromacity+luminance
format and auto-convert to RGB framebuffer values at Screen('Flip')
time via imaging pipeline. It also generally allows to convert
XYZ->RGB, which is the basis for support for other possible input color
spaces.

RenderDemo.m now demonstrates all methods to display xyY format, given
a 'cal'ibration struct and gamma table from display calibration.

This is based on the description given by David Brainard in
Psychtoolbox forum message #15092.

The code seems to work correctly and with high precision, but is only
very lightly and manually tested. A unit test is needed for safety.
This is a backup commit to document the basic working state.
RenderDemo: Refine new methods...

Skip sync tests for faster openwindow.
Add out-of-range checks to detect/mark non-displayable colors.
Set proper background clear color in XYZ or xyY input color space for a
desired RGB background output color of [0.1,0.1,0.1].
Add more documentation.
Load proper gamma tables at proper places.
PsychGPGPU: Initial commit of new folder/routines for GPGPU computing.

The Psychtoolbox/PsychGPGPU/ subfolder shall contain code for general
purpose computation on GPU's, as implemented via NVidia's CUDA, the
cross-platform / cross-vendor OpenCL, or other related toolkits and
api's.

As a starter with this commit, provide a toolkit agnostic CUDA<->OpenGL
interop interface, a mex file "memcpyCudaOpenGL" to copy image data
(textures, renderbuffers, framebuffers) between NVidia CUDA memory
buffers and OpenGL resources. This allows low-overhead data exchange
between OpenGL based toolkits and CUDA based toolkits.

Next a M-Function GPUTypeFromToGL.m: This uses the mex file to
implement interop support between Psychtoolbox and various CUDA /
OpenCL / etc. based toolkits. The idea is that at some point, the
compute backend/toolkit can be switched, e.g., between different CUDA
and OpenCL based  toolkits like GPUmat or Jacket or others and this
function abstracts whatever backend is used.

As a start it only supports interop with one hard-coded backend, the
FOSS GPUmat toolbox which uses CUDA for GPU computing in Matlab.

Also some very basic testGLInterop.m test script.

-> This works so for on 64-Bit Matlab for OSX with CUDA SDK 5.0 and
current GPUmat v0.280, but hasn't been optimized for performance yet,
and the high-level interface etc. needs work. This is just a backup
commit of the initial working state.
GPUTypeFromToGL: Change call syntax, make more flexible.

Define type of operation and type of OpenGL object to operate on.
Implement recycling for textures and gpu objects, but also now allow
creation of textures if none are provided for recycling.
GPUTypeFromToGL: Always expect textures and renderbuffers in normalized upright format.

Usercode must make sure this is the case by using proper transformation
flags in 'MakeTexture', 'OpenVideoCapure' and 'OpenMovie' as explained
in help text.

-> Want the GPU backend to receive consistent upright, non-transposed,
row-major order pixel data to avoid tears & pain.
GPUTypeFromToGL: Support low-level OpenGL objects via descriptor structs.

For use within PTB imaging pipeline, where no Screen() calls are
allowed, or from 3rd party low-level OpenGL code or Horde3D rendering
engine interface or MOGL etc.
GPUTypeFromToGL: Implemet glObjType 2: Psychtoolbox virtual framebuffer.

The drawBufferFBO aka virtual framebuffer of the imaging pipeline -
capture or write to.
GPUTypeFromToGL: Support glObjType 3 - Currently bound FBO.

Reading/Writing the currently bound FBO resp. its 1st color attachment,
allows to directly use this functionality from within processing chains
/ slots of the imaging pipeline, either as part of preflip/postflip
operations, or as part of Screen('TransformTexture').
testGLInterop: Revert to default type 0 test case.
mcmcpyCudoOpenGL: Switch to async cuda memory copies.

Makes sense, because we don't need to synchronize execution of host
code to the actual finishing of the on device copy ops, as the host
never touches those buffers. In practice, no speed gain was observed on
GeForce GT 330M.
Merge pull request #99 from simonster/texture-sharing

Fix texture sharing on nVidia Windows systems:

"Theory" of why it failed and now works with this patch applied:

wglShareLists according to doc should reject sharing if the context which is going to share resources already contains any resources. This is not the case in our code. But the context already has sharing enabled with other new context which also don't contain any resources to share yet. So either the NVidia driver has a bug and uses a too sloppy way to detect if context sharing is allowed - implying that a context who shares resources with other contexts must already contain resources, without actually checking if this exclusion criterion is really satisfied - or the Microsoft docu is sloppily written and gives wrong sharing rules. Reordering the code like you do should "fix" both possible cases.
Merge pull request #17 from Psychtoolbox-3/master

Pull context sharing fix for MS-Windows into kleinerm/master.
Merge branch 'master' of https://github.com/kleinerm/Psychtoolbox-3
PsychHomeDir: Fix weirdo failure on Matlab 7.4 + 1 Linux system.

Failed on 12.04 LTS with Matlab R2007a, nowhere else. Weird,
but just increase robustness a bit and we're fine again.
memcpyCudaOpenGL: Rename to C++ type, make it build on 64-Bit Linux.

Add support for 64-Bit Matlab on Linux. This needs switching from
C to C++ compile, although we don't use anything C++, but due to
a small bug in the CUDA-5.0 SDK for Linux (one of the header files),
that CUDA header file won't compile in pure C mode, although it is
supposed to. Simple fix: Compile our C file with the C++ compiler.

Also cleaned up all remaining bits of C++'isms in the source code.

-> memcpyCudaOpenGL.mexa64 is the new Linux mex file.
-> Tested on Ubuntu 12.04.1 LTS with CUDA-5.0 on GeForce-8800 Ultra.

Suspicion was right: Our code does things properly and (un)mapping
of OpenGL resources and async data copy is highly efficient on Linux,
yielding memory bandwidth utilization > 90% of the theoretical peak
performance of the GPU.

Ergo all the observed awful slowness is just due to the mind-blowing
poor performance of the MacOSX 10.7.5 graphics system. Running on
Linux yields close to a 100x performance gain for OpenGL-CUDA interop!
The "most advanced operating system in the world" takes things at its
own pace lol...

Still, benchmarking shows a significant performance impact due to
the register/unregister calls for OpenGL graphics resources, so these
should be avoided as much as possible. Seems i do need to implement
some fancy LRU caching scheme to reduce those calls, but only after
a good night of sleep...