Another hardware acceleration question

[drizztcanrender]

I saw the new ati 9700 graphics card and it seems to offer a lot of hardware accelerater things :)
Anyone knows if it can be used in video editing,maybe speed things up?
It says it has mpeg2 decompression and idct(as usual) but it also does color space conversion too.And it has a noise removal for captures, adaptive dieinterlacing and frame rate conversion too...Sounds interesting enough,but can we use it?

[gabest]

These hwaccel funcions are usually "write-only". It means that the picture ends up in video memory where the only remaining sensible thing to do is to display them.

[ErMaC]

Have to corroborate gabest on this - trying to use those hardware features to speed up encoding will get you about as far as trying to use the RealHollywood+'s MPEG2 decoding to transcode MPEG2 streams.

[drizztcanrender]

Ok thanks guys,i was just wondering

[UGAthecat]

actually, in the 9700, ATI did away with separate hardware decoders for video, and are using the vertex and pixel shaders for hardware video accelleration.
They are using completely closed algorithms (last I checked), but since they are using vertex and pixel shaders which M$ provides full documentation for, it shouldn't be too hard to make some filters that reproduce the same functionality. It obviously wont be as fast as ATI's versions, but should be useable on any directX 8.x supporting video card.
I've been thinking about this for a while(about 10 months now), and if it can be done correctly, it should be blazingly fast due to most directx 8 video cards having fast processors and screaming fast RAM. There are some problems, but they shouldn't be too bad.
I just wish I had more time to research this. I swear, life takes up too much of my valuable encoding-related time :rolleyes:

[gabest]

Originally posted by UGAthecat
screaming fast RAMOnly for writing, slow for reading.

[UGAthecat]

a graphics card's job is between 50% to 85% reading when rendering 3d. if reading memory was the slow part we wouldn't have anywhere near the 3d graphics performance we have now.

[gabest]

Reading from vmem to ram in 50-85% of time? What for?

[UGAthecat]

Originally posted by UGAthecat
most directx 8 video cards having fast processors and screaming fast RAM
EDIT: its all about perspective, are you reading the system memory from the GFX end, or are you reading the GFX memory from the system end, or are you reading GFX memory from the GPU?
I was referring to the GFX processor and GFX ram being fast in and of themselves, with no comment on then writing that information back to the system ram.

just for reference, the Radeon 9700 has theoretical memory throughput of 19gb per second(this is the speed I was referring to :) ).

Anything that has to be read from or written to the system ram would be much slower (less than 5gb/sec, and potentially much much slower, depending on the system)
system ram>agp>vram=fast(can be more than 8x faster than 64bit PCI)
vram>agp>system ram=slower(but still faster than PCI bus, which is capable of handling uncompressed full motion video)

The point was, since video processing (filtering especially) is heavily memory bandwidth intesive, it would be awesome to be able to work with video using a GFX card's processor to crunch video from it's memory, then take the end result and write it back to main system memory.

If you could send an mpeg2 (or some other video) stream to the gfx card memory, then decode it using the gfx card processor, then do some filters on it (again with the GPU), and send a yuv video back accross the agp bus to the system memory, the only thing left for your cpu to do would be encode the video with whatever codec you want to use. Eventually you could even re-encode the video on the gfx card, then send it back over the bus for the CPU to wrap it up in whatever container format you want to use.
The biggest problem is of course that what can be done with vertex and pixel shaders is pretty limited by the amount of instructions you can give to the shader at any one time.
Even just doing the mpeg2 decode, a nice resize algo, and sending yuv back to system ram would be cool, but the more that can be done with those shaders, the better.

[gabest]

The hw decoding in vram and sending back to ram for the codec is already possible, but I'm still not sure how fast the blt from vram to ram would be. Just try to lock on a directdraw surface in vram and do some image filtering effect on its data, it will be horribly slow.

[UGAthecat]

yeah, I know most of the hardware interaction theoreticals, but haven't had time to learn C yet, much less the amount of directx that would be required to do any of this (I've pretty much only done VB stuff so far, fairly separated from the guts of any memory transfer).
My assumption is that if you just convince the GFX card it is working on a texture, or just plain doing math for you (the easy part). then get the cpu to read the 'texture' back from the GFX card using a blt or something similarly fast, but as I said, I haven't had to work with direct access to memory before.
anyway, since I'm not even sure if we are on topic anymore, I'm gonna go sleep and maybe look into this more at a later time