MinPSPW 0.11 is out for Windows Linux and Mac
New release is out, not so many features this time:
- openTRI engine devpak
- reverted binutils to 2.16 since 2.18 generates bad assembly for Daedalus
- supports Mac as a development platform thanks to autilio
- Fixed pspsh on win32 when run inside eclipse
- added PRXTool
- get it for linux (ubuntu 32bit)
- get it for linux (ubuntu 64bit)
- get it for linux (rpm 32bit)
- get it for linux (rpm 64bit)
- get it for windows (32bit)
- get it for Mac
Thanks for the bug reports and enjoy.
Checking the availability of input on stdin
One of the things MinPSP is looking for, is native port of the homebrew SDK for their respective native platforms, so on Windows we have Windows native executables, on Linux we have Linux native executables, on Linux 64bit... you got the idea... One of the annoying things about this is that not all OSes are POSIX, and not all OSes are from Redmond, so there are quite some quirks that need to be fixed with the crancky #ifdef preprocessor statement. In my last revisit to the MinPSP code I tried to work around the lack of select on file descriptors on windows and converted the pspsh.exe binary from a cygwin binary to a 100% windows native. I isolated all socket code, sockets use select to verify the data availability and for the stdin i assumed that using _kbhit() would be enough. And it has been enough for me since for my tests i always used it from the command prompt, however a long time ago i wrote a small booklet explaining how to plug Eclipse IDE with MinPSP to make it easier to fully develop homebrew applications and there i showed how to invoke pspsh.exe from the eclipse tools. So what was the problem with Eclipse and MinPSP pspsh.exe? Well... i totally forgot that eclipse will just start the process and communicate with it via pipes!!! When you have pipes the _kbhit() function will never return a value other than 0. Having this in mind pspsh would never read anything from stdin since all I/O in the application is non blocking. So after long time of googling and testing i found this piece of code:
static int is_pipe = 0;
static HANDLE input_handle = 0;
int input_available()
{
DWORD nchars;
/* When using Standard C input functions, also check if there
is anything in the buffer. After a call to such functions,
the input waiting in the pipe will be copied to the buffer,
and the call to PeekNamedPipe can indicate no input available.
Setting stdin to unbuffered was not enough, IIRC */
if (stdin->_cnt > 0)
return 1;
if (is_pipe)
{
/* When running under a GUI, you will end here. */
if (!PeekNamedPipe(input_handle, NULL, 0, NULL, &nchars, NULL))
/* Something went wrong. Probably the parent program exited.
Could call exit() here. Returning 1 will make the next call
to the input function return EOF, where this should be
catched then. */
return 1;
return (nchars != 0);
}
else
return _kbhit() != 0; /* In "text-mode" without GUI */
}
Amazingly this code works for me, and lets me pool stdin from pipe for data available to be read. The only thing missing here is how is the is_pipe variable initialized. I've found 2 ways one using the function _isatty( _fileno(stdin)) or using Win32 API, I've chosen this way:
DWORD dw; input_handle = GetStdHandle(STD_INPUT_HANDLE); is_pipe = !GetConsoleMode(input_handle, &dw);
And that was it, now you can handle non blocking input from console and from pipes!!! Hurray!!!
Experimenting with OpenCL and Java
High Performance Computing has been always a research topic for me. I've been looking into it for a while and now that i have upgraded my laptop i own a ATI Radeon HD 4570 I can play with OpenCL. OpenCL looks very nice but it does not really integrates well with Java. I mean there are several bindings but their APIs do not seem natural to Java. It was until a few weeks ago that I found the AMD Java Zone Research Aparapi project. I decided to give Aparapi a try and installed it on my Kubuntu 10.10. Honestly I was impressed with the simplicity of the installation. I've downloaded:
Since i already had the proprietary driver from AMD installed with Kubuntu, i just unziped the Stream SDK into my home, the icd-registration to the root of the file system and the Aparapi SDK to my home. And it just works!!! I gave it a try and here is my Kernel for a bitonic sort using Aparapi:
public class BitonicSortKernel extends Kernel {
int[] theArray;
int stage;
int passOfStage;
int width;
int direction;
@Override
public void run() {
int sortIncreasing = direction;
int threadId = getGlobalId();
int pairDistance = 1 << (stage - passOfStage);
int blockWidth = 2 * pairDistance;
int leftId = (threadId % pairDistance)
+ (threadId / pairDistance) * blockWidth;
int rightId = leftId + pairDistance;
int leftElement = theArray[leftId];
int rightElement = theArray[rightId];
int sameDirectionBlockWidth = 1 << stage;
if((threadId/sameDirectionBlockWidth) % 2 == 1)
sortIncreasing = 1 - sortIncreasing;
int greater = rightElement;
int lesser = leftElement;
if(leftElement > rightElement)
{
greater = leftElement;
lesser = rightElement;
}
if(sortIncreasing != 0)
{
theArray[leftId] = lesser;
theArray[rightId] = greater;
}
else
{
theArray[leftId] = greater;
theArray[rightId] = lesser;
}
}
}
This was a good exercise to experiment with Aparapi, the SDK contains more samples, a squares compute and a mandelbrot fractal.
Performance performance performance!!!
So as I
have written before I've been playing with maps and renderers and found
this very interesting thing. My old home laptop which is a 5 year old
Sony VAIO FE11S with a intel T2400 CoreDuo 1.86GHz CPU, 2GB ram and a
NVIDIA GeForce Go 7400 256MB is as fast a Intel XEON E5520 with 8GB ram
and ATI FirePro v5700 video card. I've run the code on both machines and
the difference is minimal, so what is wrong here? Well after testing
there is nothing wrong on the code, there are no dead locks or threads
waiting for each other. What is wrong is the video card drivers. On my
VAIO I still have Windows XP SP3 and a NVIDIA driver from 2006 (because
Sony doesn't allows me to install the latest from NVIDIA). On the fast
desktop I have Ubuntu 64 bit with the crappy ATI proprietary driver.
This ATI driver is the key here since on Windows all my rendering is
done using Java2D with the DirectDraw pipeline on and it is amazingly
fast, it is also true if I use the OpenGL pipeline but the OpenGL driver
is not as good as DirectX. On linux the driver is so crap that all
rendering is done in software and a machine which I expected to be say
10x faster (it has 6x more cores, it is 64bit and the OS is also 64bit)
it just sucks.