Announcement

Collapse
No announcement yet.

Mixing open and closed source

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

  • #31
    Originally posted by bridgman View Post
    See above. I cringe every time I see an article implying that we invented DRM or are pushing it ourselves. I don't even like TALKING about DRM here for the same reason -- people start thinking it's our idea and we should "just say no". I wish it were that simple.
    I agree with you there, the HW manufacturers are NOT to blame for doing what M$ tells them to, but regardless of the cause, the consumer is still the one getting the shaft.

    Originally posted by bridgman
    Most of our sales are to big OEMs. OEMs want Windows WHQL certification from Microsoft. WHQL certification requires DRM support. If we say "no thank you, we don't want to participate in your DRM ideas" then OEMs will just buy from someone else, and the biggest chunk of our market disappears. It's possible that there might be a retail market that would accept uncertified Windows drivers and all the hassles which go along with them, but realistically I think we would be talking about Linux-consumer-only products.
    I've got another big market for you: Disenfranchised XP users. At my lan parties my friends who could afford them, are using high end NV/ATI DX9 series cards. If you'll look at the Steam Hardware Survey over 82% of people are using XP. Also notice that ATI is taking a HUGE beating on their current high-end vid cards. M$ had better be subsidizing AMD/ATI like crazy because nobody is buying their stuff.

    Originally posted by Zooko
    I can probably name a hundred people that I am friends with, or work with, or cooperate on open source projects with, who have substantially the same opinions and buying habits that I do, but I don't know if AMD has any process for learning about this subset of its customers.
    Perhaps AMD could create a web form where a person could input serial #'s from AMD/ATI products that they own (to show that they are legit customers) and leave comments/suggestions. If you got the word out about that, I'm sure you'd discover a big section of your market that is being turned off by recent hw trends.

    Comment


    • #32
      As you are from ATI and the Win drivers provide h264 encoding, how about that for Linux? That would be interesting as h264 encoding is really time consuming...

      Comment


      • #33
        In the proprietary driver -- no problem, just a question of priority relative to bug fixing, new ASIC support and other features. It's a fair amount of driver work though, unless MS brings DXVA to Linux so we can do a straight port

        In an open driver -- we're not sure yet so I'm saying "no" for now.
        Test signature

        Comment


        • #34
          a bit confused

          Originally posted by Kano View Post
          As you are from ATI and the Win drivers provide h264 encoding, how about that for Linux? That would be interesting as h264 encoding is really time consuming...
          Whenever the required support whatever that according to you comes in the driver then how can we use it.

          Will the simple daily build of mplayer svn use the hardware h264 decoding straightaway or will it require more work.

          Comment


          • #35
            Well decoding is possible using the ffmpeg - mplayer can use the built-in or external ffmpeg. Also there is a patch to use coreavc as decoder.



            No decoder is hw accellerated. But not only decoding would be nice to have, also encoding. Currently mpeg4 encoding is fast enough (could be always faster howerver) but h264 is really slow.

            Maybe somebody implements it for CUDA (NVIDIA 8 series), that would be a possibility.
            Last edited by Kano; 02 February 2008, 10:12 PM.

            Comment


            • #36
              Originally posted by Kano View Post
              Well decoding is possible using the ffmpeg - mplayer can use the built-in or external ffmpeg. Also there is a patch to use coreavc as decoder.



              No decoder is hw accellerated. But not only decoding would be nice to have, also encoding. Currently mpeg4 encoding is fast enough (could be always faster howerver) but h264 is really slow.

              Maybe somebody implements it for CUDA (NVIDIA 8 series), that would be a possibility.
              Or CTM on the ATi side of things. I know that Cuda and CTM are operate at different levels, but it should still be possible to use CTM to code an h264 codec.

              Comment


              • #37
                First off, like many other users I was to thank Bridgman for listening to users' opinions. Its nice to know that ATI/AMD cares and is implementing changes designed to accommodate Linux users.

                My 2 cents are that the DRM issue should be pushed till later. The major area where work should go is into 3D support. Right now I find the 3D support for older cards better with the open source drivers, fglrx has major artifacting with my 9500 and 9700 Pro and has since 8.35 (I'm more than willing to help debug if there is interest). Also, compiz has never worked right for me with fglrx, but works fine (albeit somewhat slowly) with the radeon drivers. Since I also have X850s I'm fairly sure this is because fewer resources are going to supporting and regression testing older cards. Since you seem to suggest r300/r400/r500 ASICS share enough commonality, I'd suggest getting those specs out to the open source developers to be a priority.

                Another area which might help is getting in contact with the WINE developers. Basically they all use Nvidia cards since the opinion is no ATI/AMD driver supports enough OpenGL extensions for it to be possible to get games working. The head WINE Direct3D developer says this outright in his recent wineconf talk: http://www.youtube.com/watch?v=eJ-zyKR1N2A I think getting Windows games running under Linux is a much bigger priority than BlueRay since games sell graphics cards, not movies.

                Comment


                • #38
                  bridgman:

                  theres just one thing i find so incredibly stupid.

                  all the drm crap is already broken, everyone that wants to copy this material already does.

                  i'd like to show a theoretical example:
                  I buy an ati card, ati has (THEORETICAL; REMEMBER) released fully open drivers. I now use my skills to modify the software stack to dump a movie. This takes a shitload of time.

                  and now for the question.. Why does it matter if i modify the ati software to do it, rather than going on a few torrent sites and getting the content? its even slower for me to do it by exploiting ati software, plus i gotta have BOUGHT the damn movie, so no matter how one looks at it, the content providers are better off with the ati driver allowing me to dump it, than without.

                  And giving the fact that it will realisticly only be a few people in the scope of the world that even has the ability(atleast few compared to all the people who has a bluray/hddvd movie), what does it matter that we now have an EXTRA, and more annoying, slower, method of extraction, which actually ends up earning content providers more money?

                  so now im about ready to make this claim: any content provider who would see these free drivers as something that should be stopped, are DIRECTLY STUPID, and doesent even know how to ensure their own continued stream of money properly.

                  And now, i have a question for you bridgman(and please keep in min that im not going after you personally, but rather AMD/ATI):
                  Does AMD/ATI feel they wish, and that its better for them, to babysit the complete and utter stupidity of some totally clueless and moronic content providers, to keep them believing in FALSE "truths", rather than directly giving their own customers what they want?

                  I already have a pretty good idea of the answer, but i would like for you to go to whomever is in charge around there in AMD/ATI, and ask them this question, because im really interrested in it, and this should clarify just how far AMD will be going, who their loyalties really is to, stupid content providers, or the customers who put the food on the table(well, ill bet some of those higher-ups of AMD gets alot of food on their own personal table from clueless content providers, but thats a different story).

                  Thanks in advance!

                  Comment


                  • #39
                    Reedman: Read post #20 of this thread.

                    Comment


                    • #40
                      Originally posted by duby229 View Post
                      I hate to be a pessimist, but just like CSS, HDCP --will-- be hacked sooner or later and a decryptor licensed under the GPL will be available. It's not a chicken and egg matter. We all know the chicken came first. HDCP will be hacked and will be made available under the GPL.

                      I personally am a firm believer that if you dont support it, then they cant enforce it. Your actions of supporting DRM only strengthen it. If you didnt support play back of DRM in your drivers in Windows --or-- Linux, then it would be impossible to enforce.

                      Taking ATi's market presence into consideration, it may well be possible for them to kill off DRM by themselves simply by not supporting it in any fashion on any product using any operation system with any driver. ATi is big enough that if they ignored DRM they could single handedly kill it. That would win over the vast majority of the video market in your favor, becouse the simple matter of fact is that if most people knew what DRM actually was they would fight tooth and nail to get rid of it ASAP.

                      As a Video company it is ATi's duty to protect its customers --from-- DRM.... That means doing everything possible to actively look for protection mechanisms, and shutting them down, or bypassing them, or at the very least making it known to the user that the content they are trying to view is infected. But instead they walk away in fear from the content mafia, and strengthen it by weakening themselves.
                      then nvidia would support it and production companies would push out everything to that boards. only an agreement between hw producers to not support it would lead to its removal, but since amd, nvidia, ati, intel and other companies were the founders of drm the problem is that the one who will get out from it would simply lose market share and will die, unless it would come out with something that would lead community to stay tuned to it. for example the new display port seems wuite promising and interesting, but i don't think that it would strike down hdmi, since it has already been established in most of the hw present around the world, and if it's not 100% compatible with this hw, maybe through a phisical adapter, then it will lose and will be remembered as one of the great hw flops. the other problem is that there's on the market enough protected content that cannot be played without hw capable of doing it and that a lot of money was invested into it that it is almost unlikely to just be removed. what would you do if you're told that the bd film you've buyed for 50 or 60$ need to be changed in order to be played on your pc?!


                      I dislike DRM so strongly that I will tend to avoid supporting products which offer even *optional* support for DRM. For example, all other things being equal, I would prefer to buy a card that does *not* support DisplayPort, because the DisplayPort standard is tainted with the stench of DRM in my mind.
                      for what i've read displayport is the free alternative to the non-free drm protected hdmi, but i might be wrong on this. i need confirmation of this statement from someone who is better informed on the matter.

                      I think getting Windows games running under Linux is a much bigger priority than BlueRay since games sell graphics cards, not movies.
                      true. this is what ports people to linux. but here there's ne need of software houses that would step to linux. id has made its move and now i'm waiting for other houses like ubisoft and blizzard. i think that the moment in which gallium and opengl 3 will be here then we'll see a native support for windows/linux games with only one code and we'll see the end of directx. only when companies would drop directx and tune to opengl (which now is starting to be faster than directx in different games), and when there would be drivers like catalyst with a good part of code that is the same for different oses then we'll see a real passage of games to linux and a lesser domination of windows in the oem's plans. but for now this simply isn't the time for it.

                      ince you seem to suggest r300/r400/r500 ASICS share enough commonality, I'd suggest getting those specs out to the open source developers to be a priority.
                      the new specs would mean more driver work than implementing new code for the radeonhd driver, because from a programmer view it's simpler to write new code than modifying old code that wasn't written by you to have it fit to your needs. the one thing that after the read of this thread has gotten in my mind is a foolish thing:
                      why not concentrating for lets say 2 weeks on identifying the stuff that is equal in the chips and what is different. then take the equal stuff based on what it does and put it into a module, put another stuff into other module and so on. make a diagram of the various features and how they were implemented or not implemented yet, then take the driver and split it based on this new diagram. for example i'd put things like this:

                      1. base atombios, from which, based on the board reads you'll start loading its modules, named radeon_core.so
                      2. a module of 2d accel for r200, r300, r400 and earlier r500 boards that could be named radeon_2d_pre600.so
                      3. a module of 3d accel for r200, 300, 400 ecc named radeon_3d_pre600.so
                      4. a module of 2d/3d accel for igps named radeon_igp_accel.so
                      5. a module of 2d accel for newer r600 named radeon_2d_hd.so
                      6. a module for 3d accel for newer r600 named radeon_3d_hd.so

                      this would mean that developing of new features would hold down for some time, but there would start the integration of the code for the various drivers. from what i've read around the future is a single radeon driver that would be ok for all the boards, but with the differences in functionality and hw implementation this would require a lot of work and superfluous code just for compatibility issues.
                      the same fglrx could benefit from this developing by removing igp features and board detection from it. then the devs would use the atombios core module for initialization and then would put on their own 2d/3d module. for the igps, if their code is so different there's a good point of splitting them from the fglrx and readeon stuff and putting them as a single big module separated from the others. in this way the developing process would be faster in the future and there wouldn't be the need to deal with compatibility code and with regressions for older cards after the implementation of new features in the newer ones.
                      this would also allow amd to easily implement modules on top of various modules for a future implementation of hw hd decoding or of other features that wouldn't be opensourced if they'd want to go on that road in the future.
                      Last edited by givemesugarr; 03 February 2008, 11:20 AM.

                      Comment

                      Working...
                      X