Announcement

Collapse
No announcement yet.

Revenge On Reverse Engineering

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

  • #16
    Originally posted by givemesugarr View Post
    the xpress 200m
    That chip is notorious under Linux... Your best bet is probably waiting for AMD to release the documentation covering that IGP.
    Michael Larabel
    http://www.michaellarabel.com/

    Comment


    • #17
      You might also want to post to the xorg-ati mailing list to see what the latest status is. Dave Airlie made a lot of progress on implementing vertex shaders in software a few months ago -- not sure if anyone has had time to push ahead since then. Alex Deucher (one of the maintainers of the oss driver for the 200M) is starting at AMD next week so that should make digging up the info a lot easier.

      Comment


      • #18
        Alex Deucher (one of the maintainers of the oss driver for the 200M) is starting at AMD next week so that should make digging up the info a lot easier.
        i've read about it some days ago about it on phoronix or on deucher's blog (i don't really recall where) and i was quite pleased about the news.

        Dave Airlie made a lot of progress on implementing vertex shaders in software a few months ago -- not sure if anyone has had time to push ahead since then
        i've tried the radeon when the famous 8.42 got released and tried to compare the two drivers but i've found out it to be a lot slower than fglrx and it had some problems with my board. it doesn't have the dedicated ram as some x200 based boards that i've seen around. when i got the pc (about 2 years ago) it wasn't usable in linux (i couldn't use it even with the vesa mode) and in windows it had a lot of problems (crashes and similar). only after 3-4 months it became stable and usable in windows xp and i could then install linux. fortunately after some months of windows enduring i've found out better and working drivers. but still the video is slow and has some performance issues. opengl is still very slow and i curently cannot really use it on linux, aiglx is still not a speedy gonzales and compiz is totaly unusable (less than 100 fps and 100% of processor speed to make the alt+tab switch in about 10 seconds). the oss drivers are still about 1/2 of fglrx in terms of speed and for that reason they're still no option. fglrx now is everyday usable and i can run old fellow beryl on it without speed decrease.
        in my opinion ati has done in one year what it should have done in more than 5 years and the release of specs would further convince me on going with an amd-ati and for that i'd really want to thank amd/ati for improving its linux drivers and for the good job they've done in the last months since i've understood that the work is done by a few hand of devs that also have to mantain the windows drivers.

        Comment


        • #19
          Originally posted by Michael View Post
          That chip is notorious under Linux... Your best bet is probably waiting for AMD to release the documentation covering that IGP.
          Notorious?? Don't you mean "evil"?

          I've got 128M of dedicated RAM with my version of the chip and I can't use it (The old driver only reliably uses the UMA configuration...I'm...hesitant...to try the new one, for obvious reasons... )- which was the reasoning behind buying it when I bought the laptop a couple of years back.

          Comment


          • #20
            here i am again asking for some clarification about revenge:
            is there some documentation on how to use it?
            i've tried looking around the web for some hours but haven't yet found a list of options or something that could help me start it and when i start revenge it says that the option that i want is not recognized.
            i think that if someone doesn't start to write some help on the matter it won't be so useful in the end.

            now, i really think that in the end amd should release proprietary modules for some features like video decoding that could be loaded by the drivers like radeon or fglrx itself. i think that doing that would prevent the people from reverse engineering (losing time figuring out stuff) protected stuff and would put amd at safe from legal issues with the proprietary stuff. also it could help out the fixing of some features that aren't planned to be outsourced. this could also speed-up the process of the developing of new oss drivers.
            for example they would load the unimplemented modules among the fglrx ones and use them until the documentation and the developing process would be mature enough to support new features.
            in my opinion this would be the best choice and would integrate the driver in a more profound way since fglrx would mainly focus on implementing proprietary stuff and on the speed of these modules while the oss community would implement and mantain the outsourced hw capabilites and would port them to new releases faster than we had them ported with fglrx.
            also, defining a communication layer for proprietary modules, for example based on opengl, thus independent from operating system, could push other devs to start creating own oss or closed drivers based on the specs and which would benefit of all the features via these modules.
            try thinking about it in this simplified term:
            at amd would develop an opengl module that controls hw video decoding. a linux developer which has this module would load it and use it via the common layer without having to worry about how the stuff works. all that it needs to know is what it has to pass to the layer and the layer would pass the right arguments to the video decoding module which would do the decoding and pass the results to the driver via the same intermediate layer. of course, the oss developer could just have the video decoded via software means without problems if he would have wanted that. the same would happen with a solaris dev: he would have these modules ready to use and he would just have to load them while he would have written the code for the documented features, if we would have felt the need for it.
            also oss modules could be used by other oss drivers via the same layer (think of solaris drivers using linux oss modules).

            now i'd like to ask bridgman if this could be a good idea and if it could be applied in the future for amd drivers.

            Comment


            • #21
              We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it
              Last edited by bridgman; 01-03-2008, 05:50 PM.

              Comment


              • #22
                Originally posted by bridgman View Post
                We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it
                i understand very well your point, but i'll ask you this: what use could be there for reverse eng the modules if someone gives you them working well?! why would someone do reverse eng on something that is working well and loose time doing this? i think it's a stupid thing.
                anyway, i agree with you that releasing something that could break your legal obligation with someone else is a stupid thing. well, i hope that amd will come out with some idea to fix this in the future.

                Comment


                • #23
                  I'd be perfectly fine with a blob for video decoding. I understand the issues here. I hope eventually the industry will wise up and realize that DRM doesn't work, but until that happens, I'd really like to have hardware accelerated video decoding, and if it can't be free, then proprietary is fine.

                  I don't expect Richard Stallman would agree, but I think it's best for everyone if free and propietary software coexist.

                  Comment


                  • #24
                    Originally posted by givemesugarr View Post
                    here i am again asking for some clarification about revenge:
                    is there some documentation on how to use it?
                    i've tried looking around the web for some hours but haven't yet found a list of options or something that could help me start it and when i start revenge it says that the option that i want is not recognized.
                    i think that if someone doesn't start to write some help on the matter it won't be so useful in the end.
                    There isn't very much documentation right now; I really should write some. There
                    is a README included with the latest Revenge from Git. I don't remember whether
                    it's included in the last release...

                    When I add PCI-ID based card detection a lot of the nastiness from interface
                    switches (AGP, PCI-E, etc) will disappear, but I haven't done that yet.

                    Btw, the email address in the README currently isn't setup, so you should send
                    dumps to me directly.

                    Comment


                    • #25
                      Originally posted by bridgman View Post
                      We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it
                      Why can't we have true HD acceleration of non-DRM'd content?

                      Comment


                      • #26
                        Originally posted by deanjo View Post
                        Why can't we have true HD acceleration of non-DRM'd content?
                        because releasing specs for the free hd video acceleration would let reverse engineering reveal how the drm works in a matter of no time and because usually the hd content (until now) was protected by drm, which is on its last moments of life after sony, the last drm sustainer, has declared that would abandon drm for some of its content - the news is on linux journal breaking news (http://www.linuxjournal.com/node/1006011 ) while the article to which it refers is available directly on business week: http://www.businessweek.com/technolo...013_398775.htm .
                        so for example if amd would reveal how udv works for the free part
                        on monday someone would have commit a patch to the radeon for the
                        drm part. at least that's what i've understood from john's explanation on the matter.

                        Comment


                        • #27
                          Originally posted by bridgman View Post
                          We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it
                          Funny thing how DRM in the end only screws the costumer ;-)

                          Comment


                          • #28
                            So hold on, let me get this straight... We are talking about DRM (Digital Restrictions Management) not DRM (Direct Rendering Manager).... Is that correct?

                            If so why cant you just bypass the frontend altogether and just let all those stream processors handle HD decoding directly through something like CTM? Or maybe through an abstraction layer like GLSL or something similar?

                            Comment


                            • #29
                              Yes, DRM like digital rights management.

                              Video decoding isn't the greatest fit with the kind of work stream processors can do, or at least nobody has figured out how to find sufficient parallelism in the decoding workload to take real advantage of the shader power. Having said that, there's a big difference between inefficient and impossible.

                              The biggest issue, I think, is that we do use the shaders pretty heavily for the rendering part of the playback pipeline so I'm not sure how much shader horespower is left on the 2400/2600 anyways.

                              Good question though...

                              Comment


                              • #30
                                I thought DRM was implemented though encryption of the encoded video data? So, to play DRM protected video, the stream has to be (roughly):

                                1) Unencrypted
                                2) Decoded
                                3) Rendered

                                Is this not right? If it is right, what is the problem with implementing 2) and 3) in the oss driver? (A pointer to a document explaining the problem would be appreciated, if such exist.)

                                I can see one other reason not to release the specs for video hw decoding on a system that is not able to play DRM'd material: it would raise the demand for undamaged material even more, thus making it even more popular to download movies in a sane format over, say, bittorrent.

                                *rant*

                                This whole thing is just sick - why not release the movies in an open, playable format that people can USE? I and many, many others would gladly pay for it!

                                *rant off*

                                Comment

                                Working...
                                X