|
|
GL Tools and OpenCL I posted a feature request a while back (or was it a bug-fix- can't remember) about the GL Tools patches with structure inputs supporting structures of float4s from OpenCL. Is this a possibility for a future version? I'd envisaged the 4th float just being ignored. Also, I've been wondering if there might be some mileage in a more flexible version of the stock Mesh Renderer patch, that incorporated some of the options of the current GL Tools structure patches (lines, line segments, texturable points with setable sizes etc.), but benefited from the speed of OpenCL, without the fps-sapping overhead of structures. What do you think, guys? a|x
|
I second that!
Also instead of ignoring the 4th value, I would suggest making it a boolean. So that the specific point/line/polygon in the structure will not render if the boolean is false.
Good idea!
And/or... you if you were rendering lines, it could cause the current line to terminate at that vertex, and another one start with the next one.
a|x
the "fps-sapping overhead" has largely been "solved" in 10.6 (solved in quotes because we haven't yet taken advantage of the fixes).
Specifically: in 10.5, structures are Always NSDictionary or NSArray backed (effectively -- they'er actually GFList backed, but functionally it's like a dict or an array). Because of that, every element (each number, string, whatever) needed to be an object, which required allocation, deallocation, and bookkeeping. This was expensive, but there weren't any other options.
On 10.6, structures can also be C-array backed, which skips the allocation, bookkeeping, and deallocation steps. The savings for this are tremendous. However, we haven't had time to sit down and poke at that new portion yet (and we're hesitant to alienate our Leopard users, as 10.6 hasn't been the resounding success that Leopard was to Tiger).
It's on the roadmap, don't worry, but it'll change a lot of paradigms when it's up and running. (the CL patches and mesh patches use this functionality to pass around vertex data without dying under the load of a bazillion objects).
Ah, I seeee....
I was assuming that OpcenCL arrays somehow resided on the GPU, and this was the reason OpenCL > Mesh Renderer was so fast (ie because the data stayed on the GPU, and never had to be shuttled from CPU > GPU and back).
Presumably, switching to the new method will speed up all the GL Tools structure patches tremendously, which is something to look forward to (not that they're slow now, of course).
a|x
You're right, they can live on the GPU -- I wasn't complete above.
Structures can be C-array backed (in memory), and also VBO-backed (live in vram). The path for both of these variants (C-Array and Vram) are similar (under casual observation, at least) compared to the Cocoa object-backed precursors, so I kinda globbed them together for brevity.
CL and Mesh renderer will typically use VBO-backed structures, unless you set flags for CL to happen on the CPU. Functionally it's the same, and performance-wise they're both dramatically faster than the old methods.
Gotcha. I suspected VBOs were involved somewhere. Is it possible to use C-Arrays in a standard API plugin, do you think?
a|x
Yes and no.
short version: I don't think so -- the official api only exposes structures as dictionaries or arrays, so you can't tweak the backing.
long version: there's technically no difference between the official api and the skankySDK, it's just that there are more expectations for your code to fulfill under the official api, and everything is opaque/hidden. If you were ambitious, you could recreate everything our plugins do using the standard API (you'd have to resort to an unbelievable amount of hackery, mind you). Executing code is executing code -- they both have the same rights and privileges once they're loaded.
(we reserve the right to exploit that should apple ever choose to disable the skankysdk ;)
Cool, thanks for the info. Maybe they'll be explicitly supported at some point in the future.
a|x