Printable View
Interesting. Still not convinced I see the advantage of a more complicated scene graph structure, though; I can do everything I need to in Flash's current setup. Is this a structure that you have to use for the GPU to handle it quickly, or would it be possible to accelerate Flash's primitive one?
Clears a few things up, but did he give any indication of how we would know that it's on? And is it any good for blitting?
Hi Sietjp,
A little subtlety about the third point :
* The FP10 detects the drivers, and the features of the graphic cards and decides if the use of the GPU mode or Direct mode can be used.
Even if the GPU or Direct mode is used, it is not sure at all that performance will be improved. For instance if a user is has a good graphic card and a slow CPU there is a good chance he will see performance improvements. On the other hand, a user having a top notch CPU and great graphic card will not see performance improvements that much. So keep in mind that the Flash Player only test if the graphic card meets some requirements to process GPU or direct acceleration, content played and current configuration (CPU, graphic card) will then leads to better or no performance improvements.
Hi Vengeance MX,
Sadly we cannot detect at runtime if hardware acceleration is currently running.
Yes, when hardware compositing is used (GPU mode), GPU power is used to process blitting, filtering, and blending tasks.
Oh, wow. Thanks for replying. :)
So copyPixels() operations would be accelerated? What would be a better choice for this to run well, GPU or direct? I'm not entirely sure that I understand the difference.
That is the real issue. Here is a simplified rundown of how the GPU works:Quote:
Originally Posted by VENGEANCE MX
You set the current states (This will essentially consist of what texture you want to draw among other properties such as alpha blending). This is essentially the slowest (As in really, really slow) common operation you can do on the GPU.
You perform a Draw call which will draw hundreds-thousands of triangles all with the same state.
You repeat the steps for each different texture you have.
This works fine for 3D models where thousands of triangles may share the same texture (And perhaps 30-50 textures total in a complex scene), but in flash you could have a hundred or so textures split up over only 200 objects which will completely drown the card in state changes without really doing anything. As well, you need to group objects by their renderStates so you are not switching back and forth between two renderStates (AKA you want to render AAABBB not ABABAB). This would require a traversal and sorting of the DisplayList. (That is why things like the SceneGraph are used, if stages are nodes then no sorting is necessary)
Basically, GPU acceleration is designed to pump hundreds of thousands of the exact same thing to the screen (Which is why it is massively parallel). This is rarely the case in flash (Although it does happen sometimes).
Oh, I see. But surely there's a limit to how many textures you can re-use? There are games with randomly-generated or user-designed content, right? Also, I'm surprised that in a detailed and varied game like Crysis there'd be enough re-usage of textures to make acceleration feasible. Why can't CPUs be optimized like this?
It is hard to explain the techniques that a game like Crysis would use to render scenes just because it takes advantage of a lot of features of the GPU that have no CPU equivalent. Crysis takes advantage of texture splatting, detail maps, instancing and pretty much every trick in the book and still hammers the computer you run it on. Also, keep in mind that its not the total number of textures but only the number that you are rendering (You don't need to switch to a car texture if you arent rendering any cars at the moment).Quote:
Originally Posted by VENGEANCE MX
User generated content is unrelated to render state switches and could be implemented in a variety of ways. Both user generated content and random content could potentially be generated/calculated completely on the GPU anyways.
The main problem is just that data in a 3d game is treated and kept in a completely different from than in flash on almost every level, and even if one bypassed all of the other issues, some parts of flash, such as tweening and vector rendering are just fundamentally not going to work very well on the GPU. So, the best solution one could put together would be performing some operations (such as bitmap operations) on the GPU and then reading it back to the CPU. The problem there is that transferring data to and from the GPU is extremely slow (The GPU is intended to push pixels to the monitor, not back to the CPU). Reading back data is almost a taboo of graphics programming. And even then, for ideal performance, the user will have to order the draw calls by texture (and hope the texture has already been uploaded to the GPU).
GPU acceleration will only be beneficial in edge cases, and under specific circumstances. Even then, when flash is standing between you and the video card I will be incredibly surprised if any major performance gains will be had (For example, you wont be able to use instancing which would probbably be the most useful technique for rendering particles and similar in flash (http://en.wikipedia.org/wiki/Geometry_instancing)). Making a separate draw call for each quad will kill performance like nothing ever seen. (http://http.developer.nvidia.com/GPU...chapter03.html ) And the sad part is that there is no way for flash to avoid making a separate draw call because it just doesn't have the right information.
Ah. Yes, Geometry instancing sounds like it'd REALLY help in a game like this. Presumably it's why Left 4 Dead can handle so many enemies; there are only a handful of different types, and they keep getting re-used.