Announcement

Collapse
No announcement yet.

GLAMOR Radeon Shows 2D Acceleration Promise

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

  • #16
    Originally posted by ssvb View Post
    In other words, the hardware vendors have just failed miserably to deliver the hardware capable of properly accelerating RENDER after all these years?

    What about the dedicated 2D hardware accelerators? Are they going to solve the problem? Seems like such dedicated 2D hardware accelerators are becoming popular in modern ARM hardware (Exynos4, OMAP4470, ...).
    X doesn't really have a huge market share compared to other OSes with other "2D" APIs which map to 3D hw better. Most of the "2D" accelerators are basic blitters with maybe some rotation or alpha capabilities which map pretty closely to the non-X "2D" APIs. Plus, as I said in my last post, newer hw does a better job of mapping to RENDER, but in order to handle it you really need a full "3D" driver just to handle RENDER. Most workstation X users don't care about "2D" performance anyway, they want OpenGL. Even with all those limitations, desktop performance (rather than theoretical benchmarks) is generally fine most users.
    Last edited by agd5f; 07-13-2012, 09:08 AM.

    Comment


    • #17
      Originally posted by ssvb View Post
      In other words, the hardware vendors have just failed miserably to deliver the hardware capable of properly accelerating RENDER after all these years?
      I don't think anyone has really tried. Applications are increasingly being written against toolkits running over 3D APIs anyways.

      Comment


      • #18
        RENDER and X APIs are in general, terrible.

        It wouldn't be smart to put resources in developing hardware specifically for APIs that everybody wants to go away.

        Comment


        • #19
          X does all sorts of 70s stuff like drawing lines and circles. Nobody uses that anymore.
          We're better off with the 3D hardware.

          Comment


          • #20
            Originally posted by barkas View Post
            X does all sorts of 70s stuff like drawing lines and circles. Nobody uses that anymore.
            We're better off with the 3D hardware.
            Says who? We are talking about RENDER extension here, aren't we?

            Comment


            • #21
              Originally posted by Veerappan View Post
              According to what's on his blog, he was already testing on a Radeon HD5770. The patches were to the xf86-video-ati driver, and they don't seem chip-specific.
              In the other thread people said it should work. I even can test it with xorg 1.13 since a compatibility patch has been commited.

              But, well, it doesn't (evergreen).

              Code:
              This is a pre-release version of the X server from The X.Org Foundation.
              It is not supported in any way.
              Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
              Select the "xorg" product for bugs you find in this release.
              Before reporting bugs in pre-release versions please check the
              latest version in the X.Org Foundation git repository.
              See http://wiki.x.org/wiki/GitPage for git access instructions.
              
              X.Org X Server 1.12.99.901 (1.13.0 RC 1)
              Release Date: 2012-07-10
              X Protocol Version 11, Revision 0
              Build Operating System: Linux 3.5.0-rc6-mainline x86_64 
              Current Operating System: Linux chrisl 3.5.0-rc6-mainline #1 SMP PREEMPT Mon Jul 9 02:52:24 UTC 2012 x86_64
              Kernel command line: root=/dev/disk/by-uuid/650b9f2f-d077-48e9-9fc2-7b6f2294599a ro init=/bin/systemd quiet radeon.pcie_gen2=1 radeon.audio=1 pcie_aspm=force nmi_watchdog=0 i915_enable_rc6=7 snd_hda_intel.power_save=1  initrd=../initramfs-linux-mainline.img BOOT_IMAGE=../vmlinuz-linux-mainline 
              Build Date: 13 July 2012  01:22:46PM
               
              Current version of pixman: 0.26.2
              	Before reporting problems, check http://wiki.x.org
              	to make sure that you have the latest version.
              Markers: (--) probed, (**) from config file, (==) default setting,
              	(++) from command line, (!!) notice, (II) informational,
              	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
              (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jul 16 23:42:35 2012
              (==) Using config directory: "/etc/X11/xorg.conf.d"
              (==) Using system config directory "/usr/share/X11/xorg.conf.d"
              (==) No Layout section.  Using the first Screen section.
              (==) No screen section available. Using defaults.
              (**) |-->Screen "Default Screen Section" (0)
              (**) |   |-->Monitor "<default monitor>"
              (==) No device specified for screen "Default Screen Section".
              	Using the first device section listed.
              (**) |   |-->Device "r"
              (==) No monitor specified for screen "Default Screen Section".
              	Using a default monitor configuration.
              (==) Automatically adding devices
              (==) Automatically enabling devices
              (==) Automatically adding GPU devices
              (==) FontPath set to:
              	/usr/share/fonts/misc/,
              	/usr/share/fonts/TTF/,
              	/usr/share/fonts/OTF/,
              	/usr/share/fonts/Type1/,
              	/usr/share/fonts/100dpi/,
              	/usr/share/fonts/75dpi/
              (==) ModulePath set to "/usr/lib/xorg/modules"
              (II) The server relies on udev to provide the list of input devices.
              	If no devices become available, reconfigure udev or disable AutoAddDevices.
              (II) Loader magic: 0x837c20
              (II) Module ABI versions:
              	X.Org ANSI C Emulation: 0.4
              	X.Org Video Driver: 13.0
              	X.Org XInput driver : 18.0
              	X.Org Server Extension : 6.0
              (II) config/udev: Adding drm device (/dev/dri/card0)
              (--) PCI:*(0:2:0:0) 1002:68c1:1025:0517 rev 0, Mem @ 0xd0000000/268435456, 0xcfee0000/131072, I/O @ 0x00002000/256, BIOS @ 0x????????/131072
              (II) Open ACPI successful (/var/run/acpid.socket)
              Initializing built-in extension Generic Event Extension
              Initializing built-in extension SHAPE
              Initializing built-in extension MIT-SHM
              Initializing built-in extension XInputExtension
              Initializing built-in extension XTEST
              Initializing built-in extension BIG-REQUESTS
              Initializing built-in extension SYNC
              Initializing built-in extension XKEYBOARD
              Initializing built-in extension XC-MISC
              Initializing built-in extension SECURITY
              Initializing built-in extension XINERAMA
              Initializing built-in extension XFIXES
              Initializing built-in extension RENDER
              Initializing built-in extension RANDR
              Initializing built-in extension COMPOSITE
              Initializing built-in extension DAMAGE
              Initializing built-in extension MIT-SCREEN-SAVER
              Initializing built-in extension DOUBLE-BUFFER
              Initializing built-in extension RECORD
              Initializing built-in extension DPMS
              Initializing built-in extension X-Resource
              Initializing built-in extension XVideo
              Initializing built-in extension XVideo-MotionCompensation
              Initializing built-in extension XFree86-VidModeExtension
              Initializing built-in extension XFree86-DGA
              Initializing built-in extension XFree86-DRI
              Initializing built-in extension DRI2
              (II) "glx" will be loaded by default.
              (II) LoadModule: "dri2"
              (II) Module "dri2" already built-in
              (II) LoadModule: "glamoregl"
              (II) Loading /usr/lib/xorg/modules/libglamoregl.so
              (II) Module glamoregl: vendor="X.Org Foundation"
              	compiled for 1.12.99.901, module version = 0.4.0
              	ABI class: X.Org ANSI C Emulation, version 0.4
              (II) LoadModule: "glx"
              (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
              (II) Module glx: vendor="X.Org Foundation"
              	compiled for 1.12.99.901, module version = 1.0.0
              	ABI class: X.Org Server Extension, version 6.0
              (==) AIGLX enabled
              Loading extension GLX
              (II) LoadModule: "radeon"
              (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
              (II) Module radeon: vendor="X.Org Foundation"
              	compiled for 1.12.99.901, module version = 6.99.99
              	Module class: X.Org Video Driver
              	ABI class: X.Org Video Driver, version 13.0
              
              [snip foobar]
              
              (II) RADEON(0): EDID for output VGA-0
              (II) RADEON(0): Output LVDS connected
              (II) RADEON(0): Output HDMI-0 connected
              (II) RADEON(0): Output VGA-0 disconnected
              (II) RADEON(0): Using exact sizes for initial modes
              (II) RADEON(0): Output LVDS using initial mode 1600x900
              (II) RADEON(0): Output HDMI-0 using initial mode 1600x900
              (II) RADEON(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
              (II) RADEON(0): mem size init: gart size :1fdff000 vram size: s:40000000 visible:fa3b000
              (==) RADEON(0): DPI set to (96, 96)
              (II) Loading sub module "fb"
              (II) LoadModule: "fb"
              (II) Loading /usr/lib/xorg/modules/libfb.so
              (II) Module fb: vendor="X.Org Foundation"
              	compiled for 1.12.99.901, module version = 1.0.0
              	ABI class: X.Org ANSI C Emulation, version 0.4
              (II) Loading sub module "ramdac"
              (II) LoadModule: "ramdac"
              (II) Module "ramdac" already built-in
              (--) Depth 24 pixmap format is 32 bpp
              (II) RADEON(0): [DRI2] Setup complete
              (II) RADEON(0): [DRI2]   DRI driver: r600
              (II) RADEON(0): [DRI2]   VDPAU driver: r600
              (II) RADEON(0): Front buffer size: 6000K
              (II) RADEON(0): VRAM usage limit set to 225212K
              (==) RADEON(0): Backing store disabled
              (II) RADEON(0): Direct rendering enabled
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              _glapi_get_proc_address called!
              Failed to compile VS: x•}
              Program source:
              attribute vec4 v_position;void main()
              {
                     gl_Position = v_position;
              }
              
              Fatal server error:
              GLSL compile failure
              
              (EE) 
              Please consult the The X.Org Foundation support 
              	 at http://wiki.x.org
               for help. 
              (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
              (EE) 
              Server terminated with error (1). Closing log file.
              Yea, there is actually binary data in the x logfile at "Failed to compile VS: x•}". • = C6 E2 95 in hex.

              Comment


              • #22
                Originally posted by ChrisXY View Post
                In the other thread people said it should work. I even can test it with xorg 1.13 since a compatibility patch has been commited.

                But, well, it doesn't (evergreen).
                It doesn't work with xserver 1.13 yet due to changes in the way modules are loaded by the xserver. See this thread:
                http://lists.freedesktop.org/archive...ly/000212.html
                In the meantime until it's fixed, it's best to reset your xserver to commit a615b90

                Comment


                • #23
                  2D acceleration in Wayland

                  Can anyone explain what the 2D acceleration in Wayland situation is?

                  Presumably Render will be dead, since it's an X extension and everyone who's used it seems to think it's crap.

                  Are toolkits and apps just supposed to use GL (ES2) directly for any acceleration they need done? Is there some other solution in Wayland, or is there likely to be one sooner or later?

                  Comment


                  • #24
                    Originally posted by agd5f View Post
                    It doesn't work with xserver 1.13 yet
                    Ok, thanks for the information.

                    Comment


                    • #25
                      Originally posted by ssvb View Post
                      Says who? We are talking about RENDER extension here, aren't we?
                      Sorry, that was a bit Offtopic.

                      Comment


                      • #26
                        Originally posted by smitty3268 View Post
                        Can anyone explain what the 2D acceleration in Wayland situation is?

                        Presumably Render will be dead, since it's an X extension and everyone who's used it seems to think it's crap.

                        Are toolkits and apps just supposed to use GL (ES2) directly for any acceleration they need done? Is there some other solution in Wayland, or is there likely to be one sooner or later?
                        There is no acceleration architecture for wayland. Apps use whatever drawing API they want, which at this point is pretty much just GL variants.

                        Comment


                        • #27
                          Using the last xorg-server git source i got the previus message error :

                          Code:
                          
                          _glapi_get_proc_address called!
                          _glapi_get_proc_address called!
                          Failed to compile VS: x}
                          Program source:
                          attribute vec4 v_position;void main()
                          {
                                 gl_Position = v_position;
                          }
                          
                          Fatal server error:
                          GLSL compile failure

                          using ths xorg-server 12.3 runs fine but i guess that not using glamor :

                          Code:
                          cat Xorg.0.log | grep glamor
                          [    17.177] (**) RADEON(0): Option "AccelMethod" "glamor"

                          Comment


                          • #28
                            Originally posted by agd5f View Post
                            X doesn't really have a huge market share compared to other OSes with other "2D" APIs which map to 3D hw better. Most of the "2D" accelerators are basic blitters with maybe some rotation or alpha capabilities which map pretty closely to the non-X "2D" APIs.
                            If the limitations only apply to old hardware, then just forget it and don't ever use this argument. Otherwise it sounds like a bad excuse

                            Plus, as I said in my last post, newer hw does a better job of mapping to RENDER, but in order to handle it you really need a full "3D" driver just to handle RENDER.
                            OK, looks like an interesting project for somebody with a lot of free time.

                            Most workstation X users don't care about "2D" performance anyway, they want OpenGL. Even with all those limitations, desktop performance (rather than theoretical benchmarks) is generally fine most users.
                            I would assume that the browsers, mail clients, pdf and document viewers, etc. are used more frequently than 3D games on typical linux desktop systems. How do you know what the users want? The current performance of open source radeon DDX is satisfactory at best, no matter how you are trying to sugarcoat it. And "generally fine" only works until the competitors deliver something significantly better.

                            And finally a practical question. What are you using for measuring non-theoretical desktop performance?

                            Comment


                            • #29
                              2D performance might be acceptable with a fast GPU and CPU, but on the slower APUs with limited performance that's definitely not the case. In any case, both Intel and Nvidia bring a lot more to the table and offer top-notch 2D.

                              Comment


                              • #30
                                Originally posted by ssvb View Post
                                I would assume that the browsers, mail clients, pdf and document viewers, etc. are used more frequently than 3D games on typical linux desktop systems. How do you know what the users want?
                                Sure, but agd5f said "workstation" users, which is a fairly well defined user base generally running specific and specialized apps.

                                I guess I don't understand the pushback -- people are effectively saying "if you need something like a full 3D driver in the ddx to get decent performance then we expect you to do it" and "OMG why are they looking at Glamour (a ddx built over a full 3D driver) ??"

                                Comment

                                Working...
                                X