Id love this to happen, and it would make things end user wise
seamless, but it would require vendor implementation, or an extension
to opengl itself... anyone know anybody on the khronos group? :)
On Jul 1, 2008, at 12:17 PM, Christopher Wright wrote:
I would love to have something like this working. However, everyone
I have spoken to tells me that the protected memory architecture
and driver model currently used forbids this sort of sharing. Im
not smart enough/knowledgeable enough to know all the details of
why, but im also stubborn enough to know there *has* to be a work
around. i wrote that weird little plugin as a one potential (but
kind of an ugly hack ish) work around.
If it really is driver/VM (virtual memory) deep, the only
workarounds would be possibly Shared Memory (/usr/include/sys/shm.h)
(not sure how that would work with non-system memory resources
though) or a kext that does the shim thing you mention later...
Id imagine some sort of API would be required to know the memory
locations of the resources on the GPU (ie, this offset / location
for texture a, etc), and that information would have to be
constantly synced between apps - but I have no idea even where to
begin for those sorts of endeavors.
Perhaps a standalone shim app that acts as a GPU server/resource
allocator, which handles 'locking' issues of who has read/write to
a texture/buffer to alleviate potential conflicts? No app would
then actually own the resources, but would send them and recieve
them from the shim layer? That sounds awefully complicated, and
would require re-thinking of the whole pipeline...
Rather than a shim, the drivers could be modified (with another gl
extension, for example) to abstract this -- they already manage
resources in exactly the same way, so I'm guessing you'd just add
some flags for shareability, and calls to set/control those flags,
and be done with it. I have no if this is reasonable, or if there's
already something like this in place.... </wildSpeculation>
--
[ christopher wright ]
[EMAIL PROTECTED]
http://kineme.net/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
