Announcement

Collapse
No announcement yet.

Broadcom Crystal HD Support For MPlayer, FFmpeg

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by bridgman View Post
    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.
    Well... If it's opened up the "right" way for Linux, it'd cover most FOSS situations anyhow... So we're just discussing mere semantics there, I think.

    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
    Heh... I'd have to agree.

    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.
    "Reasonable" estimates from my contacts and out in the open place the numbers at about the OSX level. Is Apple subsidizing the company's efforts for the OSX drivers to be at the levels they're at- or is AMD making a big investment/taking on a big risk there? If Apple's paying you, then what would we need to do to pass the hat there? If not, I think it's come time for AMD to put at least as much love into things as they do for Apple there. But, that's just me, I suppose.

    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".
    I can appreciate that. If only you could separate the content "protection" from the decode subsystems so we didn't have to resort to GPGPU type solutions to the issues.

    Comment


    • #62
      Originally posted by Svartalf View Post
      Well... If it's opened up the "right" way for Linux, it'd cover most FOSS situations anyhow... So we're just discussing mere semantics there, I think.
      Dieter uses FreeBSD, so I understand his point.

      Originally posted by Svartalf View Post
      "Reasonable" estimates from my contacts and out in the open place the numbers at about the OSX level. Is Apple subsidizing the company's efforts for the OSX drivers to be at the levels they're at- or is AMD making a big investment/taking on a big risk there? If Apple's paying you, then what would we need to do to pass the hat there? If not, I think it's come time for AMD to put at least as much love into things as they do for Apple there. But, that's just me, I suppose.
      I'm not going to talk about any Apple specifics, but I should point out that there's a big difference between supporting a single OS with a proprietary driver (which can leverage code from other OSes) and supporting a number of different OSes with an open driver (which has to be written and supported specifically for that market).

      Originally posted by Svartalf View Post
      I can appreciate that. If only you could separate the content "protection" from the decode subsystems so we didn't have to resort to GPGPU type solutions to the issues.
      Yeah, we initially thought it would be that simple but it turned out not to be the case. Separating the blocks isn't enough, you need to "combine them differently".
      Test signature

      Comment


      • #63
        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.

        Leaving out all the other FLOSS OSes makes the number of products that
        would be sold smaller than the actual number, and thus the expense harder
        to justify.

        > investment required is too large to fund it out of a speculative R&D budget

        12 people for a few months is way way way down in the noise for a company
        with 10,400 full time employees (and I suspect a bunch of tmp/contractors,
        part time, etc).

        >> 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" ?

        Uhm, I guess that sounds reasonable.

        > 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.

        > 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.

        The cost of 12 top engineers sounds big to most individuals imagining
        trying to pay for it themselves, but isn't a big risk for a company the
        size of AMD. I'm not saying it is trivial, but it isn't exactly betting
        the company. Sure there is a risk of spending more than you make in
        additional sales, but that is true of any project. Also true for
        advertising. And probably other things.

        The "goodwill" alone is probably worth the expense.

        More GPU sales leads to more CPU sales. (probably not 100%,
        but significant)

        Svartalf:
        > Well... If it's opened up the "right" way for Linux, it'd cover most FOSS
        > situations anyhow... So we're just discussing mere semantics there, I think.

        No, as mentioned above, ignoring all the other OSes makes the number of
        products sold appear to be smaller than reality.

        Documentation is presumably OS-neutral. My feeble understanding is that
        most of the code goes into X.org, thus applies to any OS running X.
        Only the device driver itself (the part that gets linked into the kernel)
        is OS specific. Some Plan-9 folks don't like X, so they may get stuck
        with work to do, but I think pretty much everyone else runs X.
        (ok what did I get wrong? :-) )

        Bridgman:
        > I'm not going to talk about any Apple specifics, but I should point
        > out that there's a big difference between supporting a single OS
        > with a proprietary driver (which can leverage code from other OSes)
        > and supporting a number of different OSes with an open driver (which
        > has to be written and supported specifically for that market).

        You appear to be trying awfully hard to twist things around as
        unfavorably as possible. The FLOSS OSes can share a lot of code.
        The proprietary version could also start with the same code and add
        the DRM crap.

        You're probably thinking that the proprietary version *can't*
        use code from the open version because it is so different.
        ATI's drivers (all of them) have a really poor reputation. So
        tossing most/all of the current binary driver, as distasteful as
        I'm sure that sounds, might be a good idea. Having a single
        driver base would be more efficient long term.

        Once the documentation is complete, it might be possible to recruit
        some of the Nouveau folks to work on ATI instead. Unless they
        actually enjoy the challenge of not having docs?

        > Stinkin' edit limit.

        Have you tried creating postings with your favorite text editor
        (emacs, 6, whatever) spell checking, then copy&paste into browser,
        and run preview. Might cut down on need for editing after clicking
        post. Personally I can't stand composing more than a very short
        reply in the browser.

        Comment


        • #64
          Originally posted by Dieter View Post
          Leaving out all the other FLOSS OSes makes the number of products that would be sold smaller than the actual number, and thus the expense harder to justify.
          Sure, but keeping the other OSes in doesn't raise the numbers that much and it adds fuzziness to the numbers which, on balance, makes things worse than leaving them out.

          Originally posted by Dieter View Post
          investment required is too large to fund it out of a speculative R&D budget
          12 people for a few months is way way way down in the noise for a company with 10,400 full time employees (and I suspect a bunch of tmp/contractors, part time, etc).
          Not the people I'm talking about. Try 12 out of maybe 30.

          Besides, I was talking about faster-than-light starships (so were you). Guessing you are talking about writing programming docs now ?

          Originally posted by Dieter View Post
          The cost of 12 top engineers sounds big to most individuals imagining trying to pay for it themselves, but isn't a big risk for a company the size of AMD. I'm not saying it is trivial, but it isn't exactly betting the company. Sure there is a risk of spending more than you make in additional sales, but that is true of any project. Also true for advertising. And probably other things. The "goodwill" alone is probably worth the expense.
          12 top engineers gets you programming docs for UVD and a few other currently undocumented bits, not drivers. Remember that most of the hardware already *is* documented.

          Originally posted by Dieter View Post
          More GPU sales leads to more CPU sales. (probably not 100%, but significant)
          Actually no, it doesn't really work that way other than for Fusion and IGP parts.

          Originally posted by Dieter View Post
          Documentation is presumably OS-neutral. My feeble understanding is that most of the code goes into X.org, thus applies to any OS running X. Only the device driver itself (the part that gets linked into the kernel) is OS specific. Some Plan-9 folks don't like X, so they may get stuck with work to do, but I think pretty much everyone else runs X. (ok what did I get wrong? :-) )
          The code that goes into those components has already been written, and the hardware has already been documented. The code is split between the Mesa, X and kernel drivers - nothing goes into X itself. Mesa (which is relatively OS-neutral) gets the largest portion, followed by the kernel driver (which is obviously not OS-neutral). The X driver mostly gets a subset of what goes into Mesa for 2D acceleration.

          I'm assuming you are talking more about video acceleration docco, where the resulting code would probably not go into X at all.

          Originally posted by Dieter View Post
          You appear to be trying awfully hard to twist things around as unfavorably as possible. The FLOSS OSes can share a lot of code. The proprietary version could also start with the same code and add the DRM crap.
          Actually, no, I'm not twisting anything. The point I'm trying to make is that MacOS drivers can leverage the existing proprietary driver code (since the MacOS drivers are also proprietary), while the open source drivers you are talking about can not.

          Originally posted by Dieter View Post
          You're probably thinking that the proprietary version *can't* use code from the open version because it is so different. ATI's drivers (all of them) have a really poor reputation. So tossing most/all of the current binary driver, as distasteful as I'm sure that sounds, might be a good idea. Having a single driver base would be more efficient long term.
          Sure, but then you are talking about thousands of man years to implement comparable functionality & performance to what we have in the proprietary drivers today into the open source drivers. Still cheaper than those FTL starships but not by much. Where is that money going to come from ?

          Originally posted by Dieter View Post
          Once the documentation is complete, it might be possible to recruit some of the Nouveau folks to work on ATI instead. Unless they actually enjoy the challenge of not having docs?
          Why would they do that ? Most of the ATI hardware is already documented, it's mostly video decode accel that is missing. The Nouveau devs work on Nouveau because they want to support NVidia hardware.

          Originally posted by Dieter View Post
          Have you tried creating postings with your favorite text editor (emacs, 6, whatever) spell checking, then copy&paste into browser, and run preview. Might cut down on need for editing after clicking post. Personally I can't stand composing more than a very short reply in the browser.
          I do that, but it doesn't help me to find *all* the problems. There are still things you only notice after the post has been up for a while
          Test signature

          Comment


          • #65
            Originally posted by bridgman View Post
            12 top engineers gets you programming docs for UVD and a few other currently undocumented bits, not drivers. Remember that most of the hardware already *is* documented.
            Sorry, I didn't say that quite right. "12 top engineers" gets you a definitive decision on whether or not we *can* open up UVD (and the other currently undocumented bits) plus documentation on the subset of currently undocumented bits which we decided *could* be opened up.

            One very likely outcome from their efforts would be a definitive decision that we can *not* open up UVD in its current form.

            Originally posted by bridgman View Post
            There are still things you only notice after the post has been up for a while
            ... and here's a good example.

            Stinkin' edit limit
            Test signature

            Comment


            • #66
              As ATI tends to stop closed source driver support for older chips it would be also interesting to know when the next cards will be unsupported in the future. Nv supports still all series 6 cards (DX9 hardware) with the latest closed source driver. As the oss driver is basically a joke when you compare speed/features when you want more than xv for video or compiz so this info would be really interesting. Also xv should at work with fglrx - full libva or even better vdpau would be great. It is a joke when you think of h264 l5.1 support...

              Comment


              • #67
                Originally posted by Kano View Post
                Nv supports still all series 6 cards (DX9 hardware) with the latest closed source driver.
                Nvidia still supports older hardware then that. Legacy doesn't equal unsupported or abandoned in nvidia land.

                Comment


                • #68
                  That's partly correct, there are agp card+kernel+xorg combination which do not work the way it would be supposed to. I know all about 3d drivers, you can be sure my nv script installs the correct legacy one. But some cards do not work with a newer kernel than 2.6.28, not even with the latest legacy driver only with an older one. You can be lucky when it works, but it not 100%, maybe around 75%.

                  Comment


                  • #69
                    Originally posted by Kano View Post
                    That's partly correct, there are agp card+kernel+xorg combination which do not work the way it would be supposed to. I know all about 3d drivers, you can be sure my nv script installs the correct legacy one. But some cards do not work with a newer kernel than 2.6.28, not even with the latest legacy driver only with an older one. You can be lucky when it works, but it not 100%, maybe around 75%.
                    Which combination? At the office I have cards dating back to Gforce 4 Ti's that are working fine on opensuse 11.3. (2.6.35 kernels)

                    Comment


                    • #70
                      Specifically the older cards in use there are:

                      4200 Ti <-AGP
                      4600 Ti <-AGP
                      6600GT <-AGP
                      7300 GS
                      7600 GT <-AGP

                      Comment

                      Working...
                      X