Announcement

Collapse
No announcement yet.

R600g Geometry Shaders Come For R600/R700

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

  • #41
    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


    • #42
      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


      • #43
        Originally posted by siavashserver
        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


        • #44
          Originally posted by siavashserver
          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


          • #45
            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


            • #46
              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


              • #47
                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


                • #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 ?
                  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


                  • #49
                    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


                    • #50
                      Originally posted by siavashserver
                      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

                      Working...
                      X