Announcement

Collapse
No announcement yet.

The ATI Radeon R600/700 Gallium3D Driver

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

  • #16
    Originally posted by bridgman View Post
    I expect the DX11 cards will catch up with the previous generations this year.

    We're kind of at the "everything seems to be working, why does nothing appear on the screen today ? It worked yesterday and I didn't change anything..." stage.

    Gallium3D changes seem to have slowed down recently, in the sense that the changes are more like enhancements than "changing the basics".
    so that means 1/3 is done .... only 1/3 left to release.

    Comment


    • #17
      Originally posted by whizse View Post
      Most likely:
      http://www.phoronix.com/forums/showp...26&postcount=5

      I wouldn't mind if Phoronix actually went out and interviewed the people involved instead, it would make a more interesting article.
      What? You think that's how journalism works?

      Oh..

      Comment


      • #18
        We will be releasing initial evergreen support in the r600c driver. The code is mostly written at this point (most of it is shared with the older generations), we're just at the hard part now where things aren't rendering right in certain cases, and tracking them down is tricky. The only thing left for release is final approval on the new IP involved. Once the initial evergreen code and docs are released, we'll probably switch our focus to gallium since that's where the community is focused. Keep in mind that the AMD plan has always been to support the driver development community, not to write the drivers ourselves. In some cases this means doing a lot of the initial work to get the information out there and to provide a working baseline to get the community started.

        Comment


        • #19
          Originally posted by agd5f View Post
          Keep in mind that the AMD plan has always been to support the driver development community, not to write the drivers ourselves. In some cases this means doing a lot of the initial work to get the information out there and to provide a working baseline to get the community started.
          Given the discussion earlier about how few people in the community really have the skills and background to do effective video driver development, I'm not sure if this is good news or not.

          Comment


          • #20
            So the only thing holding back initial 3d Evergreen support is the IP green light?

            That's good news. How about EXA/Xv? I assume that this is included, since most of it is shared with r600 and it's all on shaders anyway?

            Comment


            • #21
              don't worry, we will get HD 5870 3D acceleration in full speed five years down the road. And to make things even better, you will be able to actually afford to buy an HD 5870 by then! It will cost only a handful of dollars!

              Comment


              • #22
                Look on the bright side -- if we had Nvidia cards, we would never get open source 3d acceleration

                Comment


                • #23
                  Originally posted by elanthis View Post
                  I'd be happy just to have OpenGL 2.1 support on r700 right now. That at least would bring things up to par with what most commercial OpenGL apps require as a minimum version these days.
                  Aye agree. That's pretty much DX9 there and to me was heyday of graphics that got blown through to weirdville too quickly as it diverged from showing water nicely with the Transform and Lighting shaders and pushing lots of high quality textures. Then things got strange with with too much attention to texture post processing and just mucking about with justifying so much shader power with no more attention being paid to the hardware pipes. Sorry but it just seems stupid tryng to develope the technology to show high res textures on stupid res 2560x1600 monitors.

                  Comment


                  • #24
                    I have zero problems with high res textures and resolution. I like it.

                    But what I hate is the insane shader post processing crap! For those of you who go like "Huh?", take a look at Need For Speed: Shift. Me and a friend of mine call if NFS: Shit. No wait... NFS: Underground. When you accelerate you get such an insane motion blur. There are purple flares everywhere around 'tracks' and hit the gas and the entire screen turns into giant purple poo. It's like: "hey we didn't get gameplay already but let's now destroy the entire vision to mask it". Ulgh...

                    Seriously... death to those games. Die in a fire. Those games need to me made ilegal. Gaming got too commercial and as a natural effect all games now need to apeal to john doe no brain who wants to be a super hero by playing semi-interactive b-movie action scenes.

                    What do I love about graphics? Everyday believability, like the outdoor 'scenes' of Half-Life 2. Death to the rest...

                    Comment


                    • #25
                      What does this mean: "r600g: add support for all R6XX/R7XX asic" ? Does it mean my r600 card can worth with Galliium now?

                      http://cgit.freedesktop.org/mesa/mesa/log/src/

                      Comment


                      • #26
                        It probably means that your card will work as well as the other cards are working under r600g right now. In other words, not usable yet.

                        Comment


                        • #27
                          from the mesa/mesa git repo ( http://cgit.freedesktop.org/mesa/mesa/log/ ) I've found:

                          r600g: drop compiler stuff and switch over dumb tgsi assembler
                          Writing a compiler is time consuming and error prone in
                          order to allow r600g to further progress in the meantime
                          i wrote a simple tgsi assembler, it does stupid thing but
                          i would rather keep the code simple than having people
                          trying to optimize code it does.

                          Could someone comment onthat and explain what it means, please?

                          Comment


                          • #28
                            Jerome was working on a new shader compiler for 600g rather than re-using shader compiler code from the "classic" r600 mesa driver. That was something which needed to be done at some point (the shader compiler in 600c is really more of an assembler) but it sounds like Jerome didn't want to hold up getting the rest of the 600g driver going so he put in a simple shader compiler for now. It's what we ended up doing for the initial 600c driver so I certainly understand his rationale.

                            If your next question is "why didn't he use the shader compiler from 600c ?" part of the answer is that the input format is different between "classic" and Gallium3d drivers - one uses Mesa IR while the other uses TGSI. For 3xx-5xx the same compiler could be used because the Gallium3d wrapper code converted TGSI back to mesa IR allowing the use of the existing compiler.

                            Comment


                            • #29
                              Thanks for your quick answer

                              So, that part "...he put in a simple shader compiler for now." means, he's actually still working on that new shader compiler and that current solution (the TGSI assembler) is like a "quick and dirty" (not being really dirty) solution being less efficient/less featured/less complete?

                              Please correct me if I'm wrong.

                              Comment


                              • #30
                                Originally posted by mcgreg View Post
                                Thanks for your quick answer

                                So, that part "...he put in a simple shader compiler for now." means, he's actually still working on that new shader compiler and that current solution (the TGSI assembler) is like a "quick and dirty" (not being really dirty) solution being less efficient/less featured/less complete?

                                Please correct me if I'm wrong.
                                I think the tgsi assembler will just handle straight shader, ie shader without if/else/for/which/loop/jmp/call so it stays simple. Lot of program can be run with such assembler (r600c didn't have support for this for quite sometimes and people were using it).

                                Comment

                                Working...
                                X