AMD Releases Open-Source R600/700 3D Code

[bridgman]

I honestly still have no idea what you are talking about. WHAT IS THE NV LIBRARY YOU ARE SAYING WE NEED TO COMPETE WITH ?

When you talk about our technology, I *think* you're talking about our transcoding app, which runs over the Stream tools on the proprietary driver, so maybe you're also talking about ffmpeg using CUDA over the NVidia proprietary driver today ?

[bridgman]

I'm sorry, I just spent another half hour going through the links you posted and I still have no idea what that "NV library" is. It seems pretty clear that you want us to add GPU-assisted transcoding to the ffmpeg stack but I don't think anything like that exists for NVidia today either, so presumably we're talking about something else ??

Hopefully you can shed some light. Will check back in the morning.

[Nille]

I'm sorry, I just spent another half hour going through the links you posted and I still have no idea what that "NV library" is. It seems pretty clear that you want us to add GPU-assisted transcoding to the ffmpeg stack but I don't think anything like that exists for NVidia today either, so presumably we're talking about something else ??

Hopefully you can shed some light. Will check back in the morning.

Maybe he mean VDPAU from NV. ATI has Currently no real HW Acceleration and for XvBA there are no headers or smt like that for use it ( if its Wrong im sorry but i cant find anything about this) .

[popper]

why :angry: , OC its Stream and CUDA, unless theres another set of APIs im not aware of as yet, not every reader here or elsware have degrees in computer sciences as i assume you do, but thats no reason to be getting angree at people

Don/neuron2 that produces the DGAVCDecNV and DGVC1DecNV

http://forum.doom9.org/showthread.php?t=141104

http://forum.doom9.org/showthread.php?t=142961

said to me ..."Nvidia has a fine video decoding library and so I make use of it because libavcodec has problems that make it unsuitable for continued development.

So, for me, it's just going to be Nvidia, unless and until ATI make available a video decoding library, and not just a bunch of low-level functions.

Don "

and that seems to be the general feeling in the doom9 and other related messageboards threads, clearly someone in ATI needs to convince these developers of the popular video apps, to work with and provide mentoring and feedback.

the same for the linux HD video devs too, its not rocket science and no need to get or show anger here, you dont need to agree with my oppinion OC, mearly take it into consideration, and perhaps profit from it in the long term with better focus to those devs that can help advocate and produce long term apps results or continue on the current path and have these devs and users ignore ATI as they are doing now....

[Nille]

......

do you mean VDPAU from Nvidia ? ATI has SMT like this longer as Nvidia but not announced yet or give header files http://www.phoronix.com/scan.php?pag...vmc_xvba&num=1

[smitty3268]

I'm sorry, I just spent another half hour going through the links you posted and I still have no idea what that "NV library" is. It seems pretty clear that you want us to add GPU-assisted transcoding to the ffmpeg stack but I don't think anything like that exists for NVidia today either, so presumably we're talking about something else ??

Hopefully you can shed some light. Will check back in the morning.

I'm guessing he's just talking about VDPAU, I wouldn't worry about trying to decode that rambling if I were you.

[popper]

Maybe he mean VDPAU from NV. ATI has Currently no real HW Acceleration and for XvBA there are no headers or smt like that for use it ( if its Wrong im sorry but i cant find anything about this) .

Hi Nille, yes it might indeed be VDPAU that Don/neuron2 was refering to see:

http://forum.doom9.org/showthread.php?p=1228785#post1228785

however he's not around right now to clarify the question, but
what ever current NV means these doom9 devs are using, they are producing results people want/need, and people are starting to consider buying the cards these HD video apps are working with to speed up their video processing etc, thats the whole point, the end result and speed matters,not how you get to that point... if you even can with the HW brand and SW you have available.

its not just transcoding, its any and all options that your average user takes to get the end result, if any part of the workflow can be passed off to the GPU, thats more spare cycles for the CPUs to do other related video procesing stuff in a given timeframe, if that makes sense to you!.

[popper]

I'm guessing he's just talking about VDPAU, I wouldn't worry about trying to decode that rambling if I were you.

you consider asking for, and airing the subject of GPU assisted HD video processing with the readers here rambling ?, very odd.

"he's just talking about VDPAU" thats what message boards are for are they not ?, is "VDPAU" and "transcoding" so common now that every reader knows what that is, and how you use it, LOL

i take it then that you dont care about any potential future ATI assisted GPU code (whatever that might be, if any)being written, and diffs against the current FFMPEG codebase being submitted.

[smitty3268]

why :angry: , OC its Stream and CUDA, unless theres another set of APIs im not aware of as yet, not every reader here or elsware have degrees in computer sciences as i assume you do, but thats no reason to be getting angree at people

Don/neuron2 that produces the DGAVCDecNV and DGVC1DecNV

http://forum.doom9.org/showthread.php?t=141104

http://forum.doom9.org/showthread.php?t=142961

said to me ..."Nvidia has a fine video decoding library and so I make use of it because libavcodec has problems that make it unsuitable for continued development.

So, for me, it's just going to be Nvidia, unless and until ATI make available a video decoding library, and not just a bunch of low-level functions.

Don "

and that seems to be the general feeling in the doom9 and other related messageboards threads, clearly someone in ATI needs to convince these developers of the popular video apps, to work with and provide mentoring and feedback.

the same for the linux HD video devs too, its not rocket science and no need to get or show anger here, you dont need to agree with my oppinion OC, mearly take it into consideration, and perhaps profit from it in the long term with better focus to those devs that can help advocate and produce long term apps results or continue on the current path and have these devs and users ignore ATI as they are doing now....

Ah, OK. You're talking about the CUDA vs Stream computing on GPUs.

I agree that CUDA seems to have a much stronger mind share right now, for whatever reason.

I haven't tried messing around with either so I can't say much on the subject. Except that I really hope they both just die and OpenCL takes their place as an open (and compatible) standard.

[smitty3268]

you consider asking for, and airing the subject of GPU assisted HD video processing with the readers here rambling ?, very odd.
...
i take it then that you dont care about any potential future ATI assisted GPU code (whatever that might be, if any)being written, and diffs against the current FFMPEG codebase being submitted.

Not at all, I just found that post in particular hard to read and confusing. Perhaps "rambling" was the wrong description. I'm guessing that maybe you aren't a native english speaker?

More to the point, I didn't feel it really added much to the discussion. I'm sure bridgeman is very aware of all the people who want accelerated video decode, and if he is spending 30 minutes looking through a single post which I figured was just telling him what he already knew then I figured he should just drop the matter

I think adding some OpenCL code to the FFMPEG decoders is a pretty good idea, but I'm not really sure I see it as AMD's responsibility. OpenCL is a standard, and I think the FFMPEG devs probably have a better idea about how to write a codec than AMD does. Certainly if you look at their transcoding tool on the windows 8.12 drivers I think you may want to keep AMD as far away as possible and have them stick to the underlying video driver code