Broadcom Crystal HD Support For MPlayer, FFmpeg

[Dieter]

First off, sorry for "hijacking" the Broadcom Crystal HD thread.

Second, some might infer that I think that ATI should add an FPGA
to its GPUs. Popper does but I don't. GPUs are high volume parts,
so ASICs make more sense. (lower cost and less power hungry) Those
that want an FPGA can get an OGP OGD1 development card.

Bridgman:
>> Bridgman has posted that he doesn't care about video. So it is pretty
>> obvious why video decode is at the bottom of his priority list.
>
> That's the part I'm asking about. Where did I say that ?

Sorry, it is going to take awhile to hunt through 5,417 posts,
especially with the display connected to an old slow box
since the newer faster box refuses to talk to the display,
because some rocket scientist at ATI couldn't be bothered to
add a half dozen or so transisters to the billions and billions
already there. :-(

In the meantime, obviously it isn't an exact quote, and may well
be too loose a paraphrase of whatever it was you actually posted.

But... video decoding *is* at the very bottom of your priority list,
correct? :-( (I would love to be wrong about this.)

----------------------

Sadako:
> the same can be said for hardware video decoding, we don't really
> "need" that either, but we do want it

If I didn't *need* it I wouldn't be waiting for it before getting
a new GPU. And I really really need a new GPU. :-( :-(

> However, you're suggesting no one cares about compositing, 3D and
> a "modern desktop", all they want is video decoding.

Not what I'm saying at all. What part of

>> Instead of doing a half-assed job on all chips, pick one chip and get *everything*
>> working and working well. Then we will have a chip we can buy and use.

didn't you understand?

----------------------

deanjo:
> S3's "it kind of works" is still better the AMD's "doesn't work". I have had
> a chance to actually play around with the 540 GTX and when it came to vdpau
> I didn't encounter any issues.

This driver is binary only, correct? :-(

----------------------

The real question is: what will it take to get AMD/ATI to finish the
documention? It isn't like they don't have the resources to do this.
A letter writing campaign? Picketing corporate headquarters?
Photos of a C-level exec being naughty? Or what?

Bridgman, what would you need to finish the documention in a reasonable
time? An additional 6-8 people? 20? Or what?

[deanjo]

deanjo:
> S3's "it kind of works" is still better the AMD's "doesn't work". I have had
> a chance to actually play around with the 540 GTX and when it came to vdpau
> I didn't encounter any issues.

This driver is binary only, correct? :-(

Correct. FOSS or blob, I don't care. I just care about the end result, a working solution. It will be a cold day in hell before I sacrifice performance and features for the sake of a "warm FOSS fuzzy feeling". Five+ generation old cards with "blobs" still slaughter FOSS in features and performance even when those FOSS drivers are driving the newest generation of cards.

[bridgman]

In the meantime, obviously it isn't an exact quote, and may well be too loose a paraphrase of whatever it was you actually posted.

But... video decoding *is* at the very bottom of your priority list,
correct? :-( (I would love to be wrong about this.)

Video decode acceleration is after display, 2D acceleration, basic 3D acceleration and basic power management... partly because that seems to be the right priority and partly because determining whether we can up the video decode block will be very time consuming and may result in a "can't do it" decision anyways.

Bridgman, what would you need to finish the documention in a reasonable time? An additional 6-8 people? 20? Or what?

Not counting UVD, probably a half dozen top technical people (ie the extraordinarily rare ones) for a few months. UVD, probably about the same with the caveat that we may conclude that we can't release any information. Basically "shut down the technical leadership of the company and half the legal department for a few months".

That doesn't mean we can't do it, but it does mean it will take a while because the key people need to work on other things as well.

[Dieter]

Okay, so we need to somehow convince AMD's management to let Bridgman
hire about 12 more people. Anyone have good ideas?

I'm still wondering:
It has been 3.3 years since the first batch of documentation was released.
Therefore more than 3.3 years since the effort started. Where is the revised
UVD with the DRM crappola seperated out to make it easy to document the decoding
part?

[smitty3268]

Okay, so we need to somehow convince AMD's management to let Bridgman
hire about 12 more people. Anyone have good ideas?

Sacrificial goats?

I'm still wondering:
It has been 3.3 years since the first batch of documentation was released.
Therefore more than 3.3 years since the effort started. Where is the revised
UVD with the DRM crappola seperated out to make it easy to document the decoding
part?

I also remember Bridgman saying something to that effect would be possible way back then, but apparently it hasn't happened at all. I know i asked something to that effect about the new version of UVD (3) when it came out, and he acted like he had no idea at all about how it had changed or not, so i suspect this hasn't even started yet, if it ever will.

[bridgman]

OK, I have to ask one thing here. If you're going to dredge up things I said in the past (which is fine), please don't just type it from memory because you are likely to remember something different from what I actually said.

Dieter, the people we would need to do this quickly are generally not available for us to hire, they're the architects who have been designing our hardware and software for the last decade or so. Even if we hired a bunch of additional people, those people would still end up putting a big load on our core technical leaders, and it's that load that drives the scheduling realities here.

Dieter, what I actually said was :

bridgman: That's already on the requirements list for future chips. Won't make the next
bridgman: generation (too far along already) but the ones in early development should be
bridgman: more open-source-friendly
bridgman: I don't know how it will work out yet -- we combine stuff to reduce
bridgman: cost and improve performance so there's a price for making it too modular
bridgman: but I think decode vs drm should be OK to split out

That very limited comment (we were going to raise the issue for future UVD designs but I didn't know whether it would work out) was paraphrased by other people and gradually turned into something that sounded a lot more optimistic, but that is one of the risks of reading stuff on the internet. So far there has not been a need to redesign the UVD, just to add features to the existing design, so nothing major has changed yet.

I haven't tried the use of sacrificial goats yet, but the current approach (trying to get clear numbers on Linux market share and making a business case for increased investment) certainly has been a challenge

[bridgman]

BTW I don't want to go into details but it turned out that simply splitting drm and decode functionality was not enough.

[bridgman]

Stinkin' edit limit.

[Dieter]

> the current approach (trying to get clear numbers on Linux market
> share and making a business case for increased investment)
> certainly has been a challenge

A) s/Linux/FLOSS/

B) Without knowledge of the future or knowledge of some
parallel universe there is no way to know the market of
a product that doesn't exist. What is the market for
faster than light starships?

A *lot* of FLOSS people want/need a FLOSS GPU driver, but
buy Nvidia GPUs because they have had better luck with
Nvidia's binary driver than with any of the drivers for ATI
GPUS. Many of these would switch to ATI if there was a good
FLOSS GPU driver for ATI GPUs.

Some FLOSS people don't buy *any* new GPUs because of this.
(I am in this camp, and am even delaying buying new machines
because of this.) So the total market would get larger.

There is no way to know how many people don't run FLOSS
because of the GPU driver headaches.

(C) It is the right thing to do. I don't follow AMD closely,
but I have seen them do the right thing on multiple occasions,
and I don't recall seeing them do the wrong thing. (Hmmm
I suppose one could argue that participating in the DRM
crap is wrong, since it tramples the user's fair use.) For
example, AMD did a deal with DEC to get Alpha technology.
IntHell stole it (and got caught). Providing documentation
for products is the right thing to do.

[bridgman]

A) s/Linux/FLOSS/

Agreed, but solid market share information for the other OSes is even harder to get and including other OSes makes the numbers even fuzzier and therefore less credible when making a business case.

B) Without knowledge of the future or knowledge of some
parallel universe there is no way to know the market of
a product that doesn't exist. What is the market for
faster than light starships?

I think we could sell quite a few of them, if only because they would allow us to dump our garbage in places where people don't vote in our elections

Serious answer is that companies like ours are not investing in FTL starship development because the investment required is too large to fund it out of a speculative R&D budget, and there is not enough of a solid business case (development cost vs market return) to justify funding the work out of the operations budget (ie betting the company).

A *lot* of FLOSS people want/need a FLOSS GPU driver, but
buy Nvidia GPUs because they have had better luck with
Nvidia's binary driver than with any of the drivers for ATI
GPUS. Many of these would switch to ATI if there was a good
FLOSS GPU driver for ATI GPUs.

By "good" do you mean "comparable features and performance to competing binary drivers" ? If so, then right now we do not have a way to get there at a cost that can be justified by the increased business.

Some FLOSS people don't buy *any* new GPUs because of this.
(I am in this camp, and am even delaying buying new machines
because of this.) So the total market would get larger.

There is no way to know how many people don't run FLOSS
because of the GPU driver headaches.

Agreed, but combined with the fact that "reasonable estimates" don't suggest a huge potential market that makes it very hard to justify making a big investment or taking on big risks.

(C) It is the right thing to do. I don't follow AMD closely,
but I have seen them do the right thing on multiple occasions,
and I don't recall seeing them do the wrong thing. (Hmmm
I suppose one could argue that participating in the DRM
crap is wrong, since it tramples the user's fair use.) For
example, AMD did a deal with DEC to get Alpha technology.
IntHell stole it (and got caught). Providing documentation
for products is the right thing to do.

Companies participate in DRM implementation because without it they are shut out of at least 80% of the PC graphics market and wouldn't have enough business left to develop new products.

We are providing documentation and sample code for our products, which I also agree is a Good Thing. There are certain parts of the products which are problematic, specifically video decode, and for those parts we have always said "assume they will not be opened up, but we are going to try".