Announcement

Collapse
No announcement yet.

R600g Geometry Shaders Come For R600/R700

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

  • #46
    Originally posted by siavashserver View Post
    My concern is that AMD is going on an intentional not-so-old-hardware-ignoring-spree.
    Hmm... Apart from the minor contradiction that you posted this on an article about the availability of patches for new features on the R600g code branch...

    ...and that Geometry Shaders (ok, and the questionable-quality v1.0 UVD/OpenCL hardware) is one of the few remaining features of R600 not yet supported according to http://xorg.freedesktop.org/wiki/RadeonFeature/

    ....and that this patch starts the last remaining big chunk of work before supporting OpenGL 3.3 (the highest version of OpenGL originally supported by the R600/R700 shipped) according to http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

    ...and that this web site has repeatedly shown good performance from that driver.

    ...and the question as to why if you are so worried about having cutting edge graphics features, you aren't already upgrading your GFX card every five minutes, like most PC gamers seem to.

    ...I think I can see why you are concerned . At this stage, though, I'm far more worried that adding feature XXX that I don't need or use, use will break/degrade/change something that already works.

    Comment


    • #47
      Originally posted by bridgman View Post
      We have more resources on open source support than ever, and the pace of release is faster than ever, why run around saying the sky is falling now ?
      It's was answered in other topic.
      Originally posted by smitty3268 View Post
      Open source - where no good deed goes unpunished. (by the trolls)
      I'm really like work open source driver developers doing and it's actually great.
      Unfortunately few years ago situation with AMD drivers was much worse and people (and trolls) will blame you for that and you just have to live with it.

      Comment


      • #48
        Originally posted by bridgman View Post
        What I don't understand, I guess, is why everyone is so focused on this one thing when everything else we've released in the last 6+ years has required just as much effort as this. We have more resources on open source support than ever, and the pace of release is faster than ever, why run around saying the sky is falling now ?
        Linux just became a Steam gaming platform. The current posts are Shakespeare compared to the flaming that is going to happen when a driver drops 1.74 FPS on some random benchmark in future.

        Comment


        • #49
          Originally posted by bridgman View Post
          (scratches head) didn't we just finish releasing DPM support for hardware that was designed ~7 years ago (HD 3xxx / 42xx) ? I guess I don't understand what you would base those concerns on.
          Yes you did, and everybody in this forum appreciates that. But wasn't it a better decision to don't cut mainline fglrx support for those series before open source drivers reaching a usable state for daily work?


          Originally posted by bridgman View Post
          (scratches head again) Sorry, but nobody in the industry is going to give you a guarantee like that.
          *Grabs bridgman's hand quickly* I'm not going to support binary blobs here, but at least NVIDIA gave their customers a pretty decent support through their proprietary drivers. Rapid updates for newer xorg/kernel versions etc. But situation with AMD was opposite; New kernel/xorg server released, okay let's downgrade everything till the new driver gets released (if you are a lucky non-legacy card user of course)


          Originally posted by bridgman View Post
          What I don't understand, I guess, is why everyone is so focused on this one thing when everything else we've released in the last 6+ years has required just as much effort as this. We have more resources on open source support than ever, and the pace of release is faster than ever, why run around saying the sky is falling now ?
          Yes it's faster than before, but not fast enough yet. It would be great if AMD could hire more open source developers or magically memcpy Marek, Alex and other good developers a few more time.


          Thanks again for all your efforts on open source drivers.

          Comment


          • #50
            Originally posted by siavashserver View Post
            Yes you did, and everybody in this forum appreciates that. But wasn't it a better decision to don't cut mainline fglrx support for those series before open source drivers reaching a usable state for daily work?
            So wait, are you complaining about fglrx or the oss drivers? And do you think the same people are in charge of both?

            Comment


            • #51
              Originally posted by smitty3268 View Post
              So wait, are you complaining about fglrx or the oss drivers? And do you think the same people are in charge of both?
              Nope, it's about key AMD staff making decisions.

              Comment


              • #52
                Originally posted by siavashserver View Post
                Try running a bunch of Unigine benchamrks (heaven etc).
                Well, I did, and I got a garbled output and FPS bellow 1.

                Code:
                Loading "/home/httpd/Unigine_Heaven-4.0/bin/../data/heaven_4.0.cfg"...
                Loading "libGPUMonitor_x64.so"...
                Loading "libGL.so.1"...
                Loading "libopenal.so.1"...
                ALWrapper::init(): can't load "libopenal.so.1" library
                libopenal.so.1: cannot open shared object file: No such file or directory
                Can't initialize OpenAL wrapper. Install latest OpenAL.
                Warning "null" sound app is used
                Set 1920x1080 fullscreen video mode
                Set 1.00 gamma value
                Unigine engine http://unigine.com/
                Binary: Linux 64bit GCC 4.4.5 Release Feb 13 2013 r11284
                Features: OpenGL OpenAL XPad360 Joystick Flash Editor
                App path:  /home/httpd/Unigine_Heaven-4.0/bin/
                Data path: /home/httpd/Unigine_Heaven-4.0/data/
                Save path: /home/pejakm/.Heaven/
                
                ---- System ----
                System: Linux 3.13-gnu-daimonion x86_64
                CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ 1272MHz MMX+ 3DNow!+ SSE SSE2 SSE3 HTT x2
                GPU: Unknown GPU x1
                System memory: 2005 MB
                Video memory:  256 MB
                Sync threads:  1
                Async threads: 2
                
                ---- MathLib ----
                Set SSE2 simd processor
                
                ---- Sound ----
                NULL
                
                ---- Render ----
                GLRender::GLRender(): Unknown GPU
                OpenGL vendor:   X.Org
                OpenGL renderer: Gallium 0.4 on AMD RV635
                OpenGL version:  3.2 (Core Profile) Mesa 10.1.0-devel
                OpenGL flags:    Core Profile
                Found required GL_ARB_map_buffer_range
                Found required GL_ARB_vertex_array_object                                                                                                                                                                             
                Found required GL_ARB_draw_instanced                                                                                                                                                                                  
                Found required GL_ARB_draw_elements_base_vertex                                                                                                                                                                       
                Found required GL_ARB_transform_feedback                                                                                                                                                                              
                Found required GL_ARB_half_float_vertex                                                                                                                                                                               
                Found required GL_ARB_half_float_pixel                                                                                                                                                                                
                Found required GL_ARB_framebuffer_object                                                                                                                                                                              
                Found required GL_ARB_texture_multisample                                                                                                                                                                             
                Found required GL_ARB_uniform_buffer_object                                                                                                                                                                           
                Found required GL_ARB_geometry_shader4                                                                                                                                                                                
                Found optional GL_EXT_texture_compression_s3tc                                                                                                                                                                        
                Found optional GL_ARB_texture_compression_rgtc                                                                                                                                                                        
                Shading language:        3.30                                                                                                                                                                                         
                Maximum texture size:    8192
                Maximum texture units:   32
                Maximum texture renders: 8
                
                ---- Physics ----
                Physics: Multi-threaded
                
                ---- PathFind ----
                PathFind: Multi-threaded
                
                GPUMonitorPlugin::init(): can't initialize GPUMonitor
                EnginePlugins::init(): can't initialize "GPUMonitor" plugin
                ---- Interpreter ----
                Version: 2.52
                
                Loading "heaven/unigine.cpp" 113ms
                Unigine~# render_restart
                Loading "heaven/locale/unigine.en" dictionary
                Loading "core/materials/default/unigine_post.mat" 23 materials 50 shaders 12ms
                Loading "core/materials/default/unigine_render.mat" 47 materials 2368 shaders 26ms
                Loading "core/materials/default/unigine_mesh.mat" 5 materials 3386 shaders 25ms
                Loading "core/materials/default/unigine_mesh_lut.mat" 2 materials 1062 shaders 7ms
                Loading "core/materials/default/unigine_mesh_paint.mat" 2 materials 1158 shaders 12ms
                Loading "core/materials/default/unigine_mesh_tessellation.mat" 5 materials 3332 shaders 27ms
                Loading "core/materials/default/unigine_mesh_tessellation_paint.mat" 2 materials 2276 shaders 16ms
                Loading "core/materials/default/unigine_mesh_triplanar.mat" 1 material 112 shaders 3ms
                Loading "core/materials/default/unigine_mesh_overlap.mat" 1 material 300 shaders 5ms
                Loading "core/materials/default/unigine_mesh_terrain.mat" 1 material 813 shaders 8ms
                Loading "core/materials/default/unigine_mesh_layer.mat" 1 material 84 shaders 3ms
                Loading "core/materials/default/unigine_mesh_noise.mat" 1 material 106 shaders 4ms
                Loading "core/materials/default/unigine_mesh_stem.mat" 2 materials 2180 shaders 29ms
                Loading "core/materials/default/unigine_mesh_wire.mat" 1 material 45 shaders 1ms
                Loading "core/materials/default/unigine_terrain.mat" 1 material 1980 shaders 15ms
                Loading "core/materials/default/unigine_grass.mat" 2 materials 474 shaders 9ms
                Loading "core/materials/default/unigine_particles.mat" 1 material 109 shaders 3ms
                Loading "core/materials/default/unigine_billboard.mat" 1 material 51 shaders 3ms
                Loading "core/materials/default/unigine_billboards.mat" 2 materials 840 shaders 8ms
                Loading "core/materials/default/unigine_volume.mat" 6 materials 53 shaders 13ms
                Loading "core/materials/default/unigine_gui.mat" 1 material 82 shaders 1ms
                Loading "core/materials/default/unigine_water.mat" 1 material 533 shaders 41ms
                Loading "core/materials/default/unigine_sky.mat" 1 material 21 shaders 30ms
                Loading "core/materials/default/unigine_decal.mat" 1 material 99 shaders 3ms
                Loading "core/properties/unigine.prop" 2 properties 0ms
                Unigine Heaven Benchmark 4.0 (4.0)Unigine~# world_load heaven/heaven
                Loading "heaven/heaven.cpp" 282ms
                Loading "heaven/materials/heaven_base.mat" 7 materials 17ms
                Loading "heaven/materials/heaven_environment.mat" 13 materials 1418ms
                Loading "heaven/materials/heaven_ruins.mat" 27 materials 3476ms
                Loading "heaven/materials/heaven_buildings.mat" 58 materials 4324ms
                Loading "heaven/materials/heaven_props.mat" 10 materials 780ms
                Loading "heaven/materials/heaven_sfx.mat" 11 materials 16ms
                Loading "heaven/materials/heaven_fort.mat" 15 materials 1002ms
                Loading "heaven/materials/heaven_airship.mat" 26 materials 5465ms
                Loading "heaven/heaven.world" 19588ms
                Benchmark running
                Benchmark stopped
                Unigine~# video_grab
                Saving /home/pejakm/.Heaven/screenshots/00000.tga
                Unigine~# video_grab
                Saving /home/pejakm/.Heaven/screenshots/00001.tga
                Unigine~# video_grab
                Saving /home/pejakm/.Heaven/screenshots/00002.tga
                Unigine~# toggle render_show_triangles
                Received signal SIGTERM, termination
                http://www.dodaj.rs/f/z/Gb/wjeu7eS/00000.png
                http://www.dodaj.rs/f/1u/Dv/1FPT5Rjf/00001.png
                http://www.dodaj.rs/f/1y/q7/3uW7JFj7/00002.png
                http://www.dodaj.rs/f/13/3h/1womCZut/00003.png

                Originally posted by siavashserver
                Does it require patching or using a specific version of Linux kernel too? I have 3.12.9 here.
                I've applied a patch against 3.13.0:

                Code:
                From 4c79afe26e0aace9fc1497b72db4508308f91f08 Mon Sep 17 00:00:00 2001
                From: Dave Airlie <airlied@xxxxxxxxxx>
                Date: Thu, 30 Jan 2014 14:11:12 +1000
                Subject: [PATCH] drm/radeon: allow geom rings to be setup on r600/r700 (v2)
                
                the evergreen CS parser has allowed this for a while, just port
                the code to the r600 one.
                
                This is required before geom shaders can be made work.
                
                v2: agd5f: minor cleanup and add additional 7xx reg.
                
                Signed-off-by: Dave Airlie <airlied@xxxxxxxxxx>
                Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
                ---
                 drivers/gpu/drm/radeon/r600_cs.c     | 18 ++++++++++++++++--
                 drivers/gpu/drm/radeon/radeon_drv.c  |  3 ++-
                 drivers/gpu/drm/radeon/reg_srcs/r600 |  1 +
                 3 files changed, 19 insertions(+), 3 deletions(-)
                
                diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
                index 7b399dc..2812c7d1a 100644
                --- a/drivers/gpu/drm/radeon/r600_cs.c
                +++ b/drivers/gpu/drm/radeon/r600_cs.c
                @@ -1007,8 +1007,22 @@ static int r600_cs_check_reg(struct radeon_cs_parser *p, u32 reg, u32 idx)
                 	case R_008C64_SQ_VSTMP_RING_SIZE:
                 	case R_0288C8_SQ_GS_VERT_ITEMSIZE:
                 		/* get value to populate the IB don't remove */
                -		tmp =radeon_get_ib_value(p, idx);
                -		ib[idx] = 0;
                +		/*tmp =radeon_get_ib_value(p, idx);
                +		  ib[idx] = 0;*/
                +		break;
                +	case SQ_ESGS_RING_BASE:
                +	case SQ_GSVS_RING_BASE:
                +	case SQ_ESTMP_RING_BASE:
                +	case SQ_GSTMP_RING_BASE:
                +	case SQ_PSTMP_RING_BASE:
                +	case SQ_VSTMP_RING_BASE:
                +		r = radeon_cs_packet_next_reloc(p, &reloc, 0);
                +		if (r) {
                +			dev_warn(p->dev, "bad SET_CONTEXT_REG "
                +					"0x%04X\n", reg);
                +			return -EINVAL;
                +		}
                +		ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0xffffffff);
                 		break;
                 	case SQ_CONFIG:
                 		track->sq_config = radeon_get_ib_value(p, idx);
                diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c
                index ec8c388..84a1bbb7 100644
                --- a/drivers/gpu/drm/radeon/radeon_drv.c
                +++ b/drivers/gpu/drm/radeon/radeon_drv.c
                @@ -78,9 +78,10 @@
                  *   2.34.0 - Add CIK tiling mode array query
                  *   2.35.0 - Add CIK macrotile mode array query
                  *   2.36.0 - Fix CIK DCE tiling setup
                + *   2.37.0 - allow GS ring setup on r6xx/r7xx
                  */
                 #define KMS_DRIVER_MAJOR	2
                -#define KMS_DRIVER_MINOR	36
                +#define KMS_DRIVER_MINOR	37
                 #define KMS_DRIVER_PATCHLEVEL	0
                 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
                 int radeon_driver_unload_kms(struct drm_device *dev);
                diff --git a/drivers/gpu/drm/radeon/reg_srcs/r600 b/drivers/gpu/drm/radeon/reg_srcs/r600
                index 20bfbda..ec0c682 100644
                --- a/drivers/gpu/drm/radeon/reg_srcs/r600
                +++ b/drivers/gpu/drm/radeon/reg_srcs/r600
                @@ -18,6 +18,7 @@ r600 0x9400
                 0x00028A3C VGT_GROUP_VECT_1_FMT_CNTL
                 0x00028A40 VGT_GS_MODE
                 0x00028A6C VGT_GS_OUT_PRIM_TYPE
                +0x00028B38 VGT_GS_MAX_VERT_OUT
                 0x000088C8 VGT_GS_PER_ES
                 0x000088E8 VGT_GS_PER_VS
                 0x000088D4 VGT_GS_VERTEX_REUSE
                Edit: The patch is found here: http://www.spinics.net/lists/dri-devel/msg52745.html

                Comment


                • #53
                  Originally posted by bridgman View Post
                  (scratches head again) Sorry, but nobody in the industry is going to give you a guarantee like that. Our top technical engineers *are* going to be working on (not actually Fart Islands but that'll do for now) and we will get some of their time to support open source releases. That allocation of time has been gradually increasing over the last 5 years and will probably continue to increase, but it will still be finite.
                  Played with the thought of alternative funding models after exam. The "give all the money up-front" doesn't really give much incentive to the vendor to give support over a longer time-period. A leasing model would most likely work better (although would be more compex to implement than in busines to business transactions). You pay eg annually and the company uses money in supporting the hardware or ends up breeching the contract. Then no one can complain that something they paid for isn't supported anymore since there's an actual obligation from vendor to fulfill the leasing contract and once it's over, there's no room for complaining by the consumer.

                  Comment


                  • #54
                    Originally posted by nanonyme View Post
                    Played with the thought of alternative funding models after exam. The "give all the money up-front" doesn't really give much incentive to the vendor to give support over a longer time-period. A leasing model would most likely work better (although would be more compex to implement than in busines to business transactions). You pay eg annually and the company uses money in supporting the hardware or ends up breeching the contract. Then no one can complain that something they paid for isn't supported anymore since there's an actual obligation from vendor to fulfill the leasing contract and once it's over, there's no room for complaining by the consumer.
                    That's opening an entirely other can of worms, like the one opened with software which you don't buy but get a license to use it.
                    And FWIW : I don't see this model working with cars and houses (mortgages etc..).

                    What I don't understand, I guess, is why everyone is so focused on this one thing when everything else we've released in the last 6+ years has required just as much effort as this. We have more resources on open source support than ever, and the pace of release is faster than ever, why run around saying the sky is falling now ?
                    Show them a finger, they take the hand... Rest assured that the silent majority (and those that have no idea what driver they're using) appreciate very much the effort gone into r600g. I certainly do.

                    Serafean

                    Comment


                    • #55
                      Originally posted by Serafean View Post
                      That's opening an entirely other can of worms, like the one opened with software which you don't buy but get a license to use it.
                      And FWIW : I don't see this model working with cars and houses (mortgages etc..).
                      Well, as said, with business to business leasing entire computers is *very* common (support contracts are easier that way: lease ends, support ends, new computer). But yeah, doing it just on parts instead of with entire computers would already be complicated enough, let alone having it done with individual customers instead of representatives big enough to sue the vendor. I guess it doesn't really work except in b2b.

                      FWIW I also appreciate the effort by AMD. Seems Alex has had time, whether allocated or not, to review code back with Glamor which is *nice* given Glamor has a lot of potential for reducing development and maintenance cost in the future.

                      Comment


                      • #56
                        Originally posted by bridgman View Post
                        What I don't understand, I guess, is why everyone is so focused on this one thing when everything else we've released in the last 6+ years has required just as much effort as this. We have more resources on open source support than ever, and the pace of release is faster than ever, why run around saying the sky is falling now ?
                        For end users, Linux wasn't a big deal up until now. Now with SteamOS and more developers interested in Linux as a gaming platform alternative to Windows, people expect those graphic drivers to be working by now.

                        The times, they are changing.

                        Comment


                        • #57
                          Originally posted by Dukenukemx View Post
                          For end users, Linux wasn't a big deal up until now. Now with SteamOS and more developers interested in Linux as a gaming platform alternative to Windows, people expect those graphic drivers to be working by now.

                          The times, they are changing.
                          Pretty much this -- the biggest thing holding back Linux is graphics drivers and I know a lot of people who are frustrated because of the graphics drivers not being as good as Windows. Since a decent amount of games have been ported, they expect graphics drivers to just work -- but they don't.

                          Comment


                          • #58
                            Originally posted by siavashserver View Post
                            Just reading (selectively sometimes) is not enough.


                            My concern is that AMD is going on an intentional not-so-old-hardware-ignoring-spree.

                            For example is there any guaranties that AMD will keep working on feature parity and OGL4 support for 5/6/7K series in up coming years like new R series? Is there any guaranties so we will not hear anymore "Our top technical engineers are busy with new Fart Islands" or "7000 series are totally different. LOL" from AMD?
                            We already support just about all of the non-3D features on newer chips (UVD, DPM, display, etc.). In addition to working on the code, we also put a lot of effort into 3D documentation. So even if we are not able to implement every GL feature you might want, the documentation and knowledgeable developers are available to help. This is a perfect example. Dave took the documentation and implemented GS support for r600g.

                            I don't really understand why there is so much rage directed at AMD. With the exception of open source UVD support for a couple of older asics (which there is still a good chance of getting released), the open source driver is pretty much feature complete for chips up through r7xx else once the GS patches land. Other vendors have chosen not to support similar features and they don't seem to get nearly the amount crap that AMD does. When Intel releases new GL features for newer asics hardly anyone makes a peep about not supporting it on older asics.

                            Comment


                            • #59
                              Originally posted by agd5f View Post
                              We already support just about all of the non-3D features on newer chips (UVD, DPM, display, etc.). In addition to working on the code, we also put a lot of effort into 3D documentation. So even if we are not able to implement every GL feature you might want, the documentation and knowledgeable developers are available to help. This is a perfect example. Dave took the documentation and implemented GS support for r600g.

                              I don't really understand why there is so much rage directed at AMD. With the exception of open source UVD support for a couple of older asics (which there is still a good chance of getting released), the open source driver is pretty much feature complete for chips up through r7xx else once the GS patches land. Other vendors have chosen not to support similar features and they don't seem to get nearly the amount crap that AMD does. When Intel releases new GL features for newer asics hardly anyone makes a peep about not supporting it on older asics.
                              Alex, haters are going hate anyways. It seems that the people extrapolate their bad experience with the catalyst driver under linux (which is in essence much worse that open drivers) to the whole company. I saw a big number of linux users which don't believe that AMD's open drivers can be used for something more demanding than glxgears.

                              I hope most of the community really appreciate what you guys are doing. In one year the radeonsi driver already reached a point where it has some features missing in fglrx (runpm, vdpau etc). So thank you very much for your work!

                              Comment


                              • #60
                                Originally posted by agd5f View Post
                                I don't really understand why there is so much rage directed at AMD.
                                The more you are in the news at Phoronix, the more chances people have to complain. It's really that simple.

                                Over the years the complaints have changed. The people making them haven't.

                                Comment

                                Working...
                                X