ATI, please release an Open UVD API

[droidhacker]

This is what AMD devs wish for. In that case they don't have to bother with the documentation and people will stop bashing them for this...

... did you have a point to make?

[archibald]

Some of the information about my ancestors suggests that they may have merely lived under a bridge.

Mr. Bridgman, are you suggesting that you are *dun dun DUH* part TROLL? I think that would blow my mind

[HokTar]

... did you have a point to make?

I was just a bit sarcastic. Never mind.

[popper]

HokTar
Quote:
Originally Posted by droidhacker
UVD is VERY VERY quickly starting to look uninteresting. XvMC on G3D!! WOO!!
This is what AMD devs wish for. In that case they don't have to bother with the documentation and people will stop bashing them for this...

... did you have a point to make?

it seems he made his point perfectly clear.

you seem very easy to impress even though there's no production ready XvMC on G3D yet, and dont forget we are told that the UVD fixed ASIC was really only for the 'super terminal' use in the work station market place, where AMD make its money.

OC there's always the flip side of using that cheap fixed ASIC UVD option, were/when the 'work station' markets start using more flexible video demand's and yet need to reduce cost's in the start of the next financial quarter/Year..

they may in fact move over to the integrated Intel sandy bridge CPU at that time, and that means every single super'work station' will have the internal Encode/Decode engine and Gfx core included in the price, no discreet Gfx card required anymore, and thats a bit of a pickle for AMD as the UVD3 (3B ?) wont be integrated into the new AMD's CPUs going into the super work station markets ,or will it ?, and can they meet Intel Sandy bridge timelines.

but UVD3b (everyone likes a freebee) or whatever does not have (SD/HD x264 type visual quality ?) Encode capability anyway, as i say a bit of a pickle, so price war in the super terminal market it is then hmmmm

[bridgman]

Not sure I understand your point. Are you suggesting that the Sandy Bridge GPU (whether with open source drivers or a hypothetical workstation-oriented proprietary driver) will have comparable 3D performance to a midrange or high-end discrete GPU with proprietary drivers (which is what the workstation market generally buys) ?

[popper]

Not sure I understand your point. Are you suggesting that the Sandy Bridge GPU (whether with open source drivers or a hypothetical workstation-oriented proprietary driver) will have comparable 3D performance to a midrange or high-end discrete GPU with proprietary drivers (which is what the workstation market generally buys) ?

keeping in mind we are in the "ATI, please release an Open UVD API" thread OC.

well that's the point isn't it, we dont know what the quality of the SB Encode/Decode is yet really,as the x264 patch is not available just yet, and i dont think you have took a commercial x264 licence yet and working under NDA to produce something interesting and far more use outside the workstation market.

and AMD Did put the UVD decoder in there to satisfy this very same workstation market YES?

the new Sandy Bridge GPU again is really an unknown right now, but at least that has a lot of dev's porting code to it and running tests to get it working to a good standard, so the question seems to be, IS it 'good enough' for this key market and will they be inclined to save the budget by using it

the question of "comparable 3D performance to a midrange or high-end discrete GPU with proprietary drivers" doesn't seem relevant in this UVD verses SB Encode/Decode engine for the workstation market, UVD is what you chose to put on there as it meets their Need and they use UVD right now yes!

[droidhacker]

it seems he made his point perfectly clear.

You are very confused.
He didn't say anything new, he didn't provide a new level of understanding over anything. He simply stated what is already VERY WELL KNOWN.

you seem very easy to impress even though there's no production ready XvMC on G3D yet,

No, we have one that is marginally functional, but functional nevertheless.

No, I am NOT easy to impress, but when changes happen that ARE VERY IMPRESSIVE, I certainly will be.

Do you want to know what is impressive?
Got a little teaser message on Friday. Come back on Monday, and the thing is FUNCTIONAL! That is WICKED fast.

and dont forget we are told that the UVD fixed ASIC was really only for the 'super terminal' use in the work station market place, where AMD make its money.

VERY VERY VERY confused, you are..... the workstation market is where AMD makes its money ***IN LINUX***. The UVD was put there for WINDOZE REGULAR USERS who want to watch bluray disks.

OC there's always the flip side of using that cheap fixed ASIC UVD option, were/when the 'work station' markets start using more flexible video demand's and yet need to reduce cost's in the start of the next financial quarter/Year..

This is totally indecypherable. Could you please rewrite that though?

they may in fact move over to the integrated Intel sandy bridge CPU at that time, and that means every single super'work station' will have the internal Encode/Decode engine and Gfx core included in the price, no discreet Gfx card required anymore, and thats a bit of a pickle for AMD as the UVD3 (3B ?) wont be integrated into the new AMD's CPUs going into the super work station markets ,or will it ?, and can they meet Intel Sandy bridge timelines.

Intel crippleGPU won't be impressing any workstation graphics users, so that theory goes straight out the window.

Also, fixed setting h.264 encoder won't be impressing anyone doing professional video encoding. Get that cheesy sony-look on your next BD movie....

but UVD3b (everyone likes a freebee) or whatever does not have (SD/HD x264 type visual quality ?) Encode capability anyway, as i say a bit of a pickle, so price war in the super terminal market it is then hmmmm

Again, there appears to be a major disconnect between your thoughts and your keyboard. Are you saying something about UVD not having an encoder? Well guess what? Gallium CAN be an encoder!

You just argued for gallium, where the rest of your rant was about how great intel is. FOCUS!!!

[Jimbo]

the new Sandy Bridge GPU again is really an unknown right now,

The rumors points that it will have a performance similar to an HD5500. Which it is a big improvement over current intel gpus. Most impressive is that the next generation, intel ivy bridge, is expected to double sandy bridge gpu performance.

[droidhacker]

The rumors points that it will have a performance similar to an HD5500. Which it is a big improvement over current intel gpus. Most impressive is that the next generation, intel ivy bridge, is expected to double sandy bridge gpu performance.

As you say... RUMORS!!!

Intel graphics are a massive turd, don't be expecting them to suddenly make something that's actually mediocre -- mediocre is far better than intel.

[evolution]

(a bit off-topic: ) Intel Graphics hardware has a perfomance very FAR, FAR away of what we get with a discrete ATI or nVidia graphics card... So, I don't expect anyone interested in very heavy video editing to use Intel Graphics hardware on their workstations... (Most people on linux will (still) use QuadroFX of FireGL hardware for video editing).

About the subject: I'd prefer to have a proprietary yet functional UVD API with H264, VC-1 and MPEG-2 decoding, (similar to what nVidia actually provides us (with VDPAU)) than an Open-Source implementation that could be risky to be implemented, due to patent infringing (personally, I hate patents). So, I think the best way to provide us an "Open UVD API", would be, instead of releasing the UVD API to the open-source community, use the graphics card shader capabilities to decode H264, VC-1, MPEG-2 formats on hardware...

These were my "2 cents"...

Cheers