>From a theoretical perspective I would like to check that I understand how drivers work. My understanding is that there are ranges of memory addresses which are mapped to hardware. A driver communicates with the hardware by writing bytes to and reading bytes from the memory addresses which have been assigned to that device. The driver then knows how to communicate the right bytes for the specific hardware but will expose developer or O/S friendly functions to be invoked by programs. I have never written a driver so this is just the theoretical model I have in my head.
What I wonder is whether a mechanism could be put in a VM such that it can optionally load drivers such that it has very fast access to the GPU. This would mean the driver was inside the VM and in theory that would make it pretty fast. In theory also though there is a danger of the O/S and the VM getting in a contentious state. If the VM has access to the GPU it certainly means the possibility of optimising execution across CPU and GPU. In addition the VM would be plugged into the graphics capabilities and be able to render very fast. I don't know if this is feasible or if the VM and GPU vendors would be interested in doing this. It just might help in competing with native code by eliminating a layer that API calls need to go through. Maybe the Overheads are not as bad I would think. Perhaps even going through the O/S, if the bridge is in the VM rather than an external library going through JNI. I know JNI calls certainly have overhead but the VM itself is native and may not have to go through all the JNI procedures which cause the overhead. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
