On 12/13/05, Christian Klippel ck@mamalala.de wrote:
hi all,
Am Dienstag 13 Dezember 2005 18:22 schrieb chris clepper: [...snip...]
Premiere is probably not texturing the video using OpenGL, but rather using simple accelerated overlays.
How do you intend to improve things? What alternativs do I have? Does it run smoothly in Mac? Is this a PC-only issue?
I easily get 4 720p24 clips on a dual G5 and at least 3 1080i60 ones. At least 6 DV clips are possible as well.
the real bottleneck here isnt the cpu, nor the gfx card, but the bus, either agp, pci, whatever. for a dual g5 it just sucks to handle only 4 clips, as well as for any other modern machine.
Except the half-dozen lines of Apple specific GL code we use in GEM that turns on full DMA uploads of YUV textures makes HD possible on that platform. On the Windows side I haven't found the critical DMA path for NV or ATI. It is possible for the hardware to do, but if the functionality isn't exposed then it's lost.
open gl isnt meant for doing video stuff, thats it. you cant expect your machine to pump excessive amounts of data through the bus to the card just because that particular card's open-gl is fast. it wouldnt be a big problem to project the same video onto many objects with little effort, since it would be uploaded only once. but having three videos means 3 times the data is flowing through the bus.
Again, GL/AGP/PCIe is just fine for handling large video streams as long as that functionality is available.
im pretty sure that it would be more performant to do the raw mixing on the host cpu and the use the result to feed gem...... even more when doing that with optimized mmx/sse/altivec code. the gfx card may be theortical able to that as well, probably more complex arrangements as well, but it comes to an halt when it comes to transfer the seperate streams to the card ....
Spreading the work equally between CPU and GPU is the fastest path.
One of the recent projects here had 16 640x480 textures of which about 6 to 8 played at 30 fps at once and all of the mixing, color treatment and transparency was done on the GPU. The Altivec code I wrote to do the same is pretty good, but at a certain level you just run out of CPU cycles. In this case the decompression of the video clips and recording of the incoming live camera video took up the CPU resources. Turning off DMA texture uploads increased the CPU load almost 60%, so that is of course critical to have.
maybe a way would be to implement the decompression onto the gfx card itself, so that the compressed streams can go directly to the card, either mpeg, mjpeg, or whatever.
That would be great to have, but again we run into the fact that even though the cards may already do this, there is not a way to really access the feature in GEM. For example, the GPU hardware MPEG-2 decoder is used by a number of DVD applications, but the path provided does not allow for the decoded frames to be used in an OpenGL context. ATI has a new system coming that may allow that though.
greets,
chris
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list