Announcement

Collapse
No announcement yet.

Recommendations for a netbook with 3D accelerator?

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

  • #16
    Well xbmc was the only app that managed to show vc1 with vaapi with ion1 via vdpau, with mplayer+vlc i got errors. Intel can not accellerate vc1 at all, but when you only dl the movies you get mainly h264 l5.1. in that case intel i3/i5 duals with onchip vga might be interesting. vaapi is not bugfree there but its improving. For full features get nvidia gfx, thats clear. Stay far away from ATI when you want working video accelleration with Linux.

    Comment


    • #17
      Originally posted by Kano View Post
      Well xbmc was the only app that managed to show vc1 with vaapi with ion1 via vdpau, with mplayer+vlc i got errors. Intel can not accellerate vc1 at all, but when you only dl the movies you get mainly h264 l5.1. in that case intel i3/i5 duals with onchip vga might be interesting. vaapi is not bugfree there but its improving. For full features get nvidia gfx, thats clear. Stay far away from ATI when you want working video accelleration with Linux.
      Yep, it's kind of painfully clear, now. EVGA has some interesting offers. Too bad they don't seem to include trade-ins on Radeon boards.

      As for MPlayer and VLC: your experience is going to depend a lot on whose packages you're using, when they were built, whether something extra was pulled from git / SVN, whether completely out-of-tree patches made it in, and so forth. --and there's that strong dependency on ffmpeg, which is quite the moving target.

      .deb packaging remains a mystery to me (RPM and Portage seem easy by comparison...), but I'm thinking hard about installing enough development packages to roll my own SMPlayer, MPlayer, and VLC. My firewall / router / NTP proxy / file server / who knows still runs Gentoo-- until I have time to upgrade it to Ubuntu Server 10.04 --so I'm not exactly a stranger to rolling my own code; I have an entire overlay of my own, including ffmpeg and Transmission svn ebuilds with minor custom patches of my own.

      Comment


      • #18
        The OSS driver does not support post-R5x0 GPUs. I have no use for a 2D-only-accelerator that doesn't even really accelerate 2D. I don't really care that the not-in-kernel, not-in-XOrg-release-branch R6x0 code "just got texture support".
        Umm..

        OpenGL vendor string: Advanced Micro Devices, Inc.
        OpenGL renderer string: Mesa DRI R600 (RV710 954F) 20090101 TCL DRI2
        OpenGL version string: 2.0 Mesa 7.8.2
        OpenGL shading language version string: 1.10
        HD2k - HD4k are pretty well supported in the open-source (classic) drivers. It's a different driver for HD2-4 that just got textures

        Comment


        • #19
          @rmenessec

          Maybe you did not notice that i worte scripts to compile always the latest versions of the apps i test. All comments are about the latest revisions.

          Comment


          • #20
            Originally posted by rmenessec View Post
            [*]R3x0-R5x0 performance with OSS drivers is pretty miserable compared to the last (ancient) blob, which is now unusable with vaguely modern X.Org
            The "last ancient blob" had years of performance optimization work on top of a major rewrite of the OpenGL stack, so it sets a higher performance bar than you might think. 2D performance on the OSS drivers is probably still as good as or better than the 9.3 fglrx driver, however the 3D focus right now has been on features & architectural improvements, not performance tuning. I think you'll see performance work start to ramp up over the next year. Are you running the Gallium3D driver or classic mesa HW driver right now ?

            Originally posted by rmenessec View Post
            [*]R3x0-R5x0 power saving does not exist in a readily usable state, nor video decode in any state (that I'm aware of)
            Power management was just implemented, so you either need to pull very recent kernel code or wait until your favorite distro picks it up. There is no useful video decode hardware in 3xx-5xx GPUs (the old IDCT block is MPEG-2 only and we stopped using it in the proprietary drivers because decoding on the CPU was faster and more efficient) so not sure what you are looking for in terms of driver support.

            Originally posted by rmenessec View Post
            [*]The OSS driver does not support post-R5x0 GPUs. I have no use for a 2D-only-accelerator that doesn't even really accelerate 2D. I don't really care that the not-in-kernel, not-in-XOrg-release-branch R6x0 code "just got texture support".
            Huh ? The articles are about the new Gallium3D driver that Jerome is working on, not the "classic" Mesa 3D driver which has been available on 6xx/7xx for over a year.

            Originally posted by rmenessec View Post
            [*]The blob is completely unsupportable. Horrible 2D performance, no coherence with kernel or X.Org releases, no video decode. I'm aware libxvba exists. I'm discounting it until it does something.
            Are you sure about "horrible 2D performance" ? It was always OK until distros stopped shipping the Fedora "no backfill" patch, and one of our devs provided a "backclear" patch which provided the same performance without the side effects that "no backfill" caused on Intel hardware. The new 2D acceleration (turned on for the first time in 10.6 IIRC) gives you good 2D performance without requiring the backclear patch, although there are still some app compatibility issues being worked through.

            Comment


            • #21
              I think you only heard about fglrx, you never used it. When you test fglrx with squeeze you get always corruptions with the new "accellerated" codepath and kde 4 composite is sometimes even disabled. That does not occur with latest intel hd graphics which has got vaapi for h264 (up to l5.1) even with oss drivers. Where is vaapi for radeon oss?

              Comment


              • #22
                Originally posted by bridgman View Post
                Are you running the Gallium3D driver or classic mesa HW driver right now ?
                Sorry, neither. EVGA GTX in the workstation. I've got one HIS X1550 in the firewall because I wanted to reclaim the system RAM from the GMA4 IGP. One in the media PC (Windows) because that's what I had available. Everything else is using Intel IGPs because it doesn't need anything better or it's a laptop where I didn't have any choice at the time, or cheap NVIDIA boards.

                Originally posted by bridgman View Post
                Power management was just implemented, so you either need to pull very recent kernel code or wait until your favorite distro picks it up. There is no useful video decode hardware in 3xx-5xx GPUs (the old IDCT block is MPEG-2 only and we stopped using it in the proprietary drivers because decoding on the CPU was faster and more efficient) so not sure what you are looking for in terms of driver support.
                I know reclocking was just implemented. I don't want to have to go through the hassle of trying to backport kernel patches myself. Building my own media players and back-end libs is already too much like work; screwing up a kernel backport could really ruin my whole day-- esp. while ext4 and btrfs are neither of them fully-baked. I'd really rather something I can just use.

                I'd like to totally offload at least one full video decode stream from the CPU(s) and have tweakable upsampling, downsampling, and artifact removal. I don't know if VDPAU / VA-API allow anything at all besides offloading, but at least it's something, and I'm looking at Atoms and ULV Ci3/Ci5 which could really use the help. Even MPEG-2 offload (and esp. upsampling / processing) is more strain than I want while a bittyamd64 is trying to render a web page in, i.e., Fox 4.

                (Has anyone ever determined whether GPUs or dedicated DSP solutions like the new BCM cards can or do use less power than on-CPU decode? I'd be interested to know.)

                Originally posted by bridgman View Post
                Huh ? The articles are about the new Gallium3D driver that Jerome is working on, not the "classic" Mesa 3D driver which has been available on 6xx/7xx for over a year.
                It's been a while since I was lurking on Freenode and politely nudging to know when >= R6x0 support would be finished, so I'll grant I may be out of touch.

                Originally posted by bridgman View Post
                Are you sure about "horrible 2D performance" ?
                Yes. Phoronix and my own benches seem to quite clearly bear out the theory that the Windows drivers are far, far faster, "Direct2D" or no.

                Bringing this back on-topic: It doesn't even matter any more. I'm decommissioning all the old junk, so the question is about R700/R800 AMD and 200- / 400-series NVIDIA.

                Comment


                • #23
                  Actually, I could use some clarification: what GPU series are the "embedded" AMD SKUs? Being caught by a cut-off of R6x0 driver support in The Blob would be disastrous.

                  Same question for the NVIDIA embedded GPUs / IGPs / whichever.

                  Comment


                  • #24
                    In the case of AMD, I think the current offerings are the E2400 and E4690, closest to HD2400 (6xx) and HD4670 (7xx) respectively :

                    http://www.amd.com/us/products/embed...-graphics.aspx

                    On the IGP side, looks like the 785, 780 and 690 are offered (6xx, 6xx and 4xx 3D core respectively) :

                    http://www.amd.com/us/products/embed.../chipsets.aspx

                    I'm not sure what the corresponding NVidia parts are.

                    Comment


                    • #25
                      Originally posted by rmenessec View Post
                      Yes. Phoronix and my own benches seem to quite clearly bear out the theory that the Windows drivers are far, far faster, "Direct2D" or no.
                      That's not necessarily a driver issue though, is it ? The Linux/X 2D graphics framework is essentially all indirect rendering, while Windows 2D is all direct rendering.

                      Not saying that it isn't a driver issue, but I was expecting a Linux vs Linux comparison (eg "brand X Linux HW+drivers have much faster 2D than yours").

                      Comment


                      • #26
                        Originally posted by bridgman View Post
                        That's not necessarily a driver issue though, is it ? The Linux/X 2D graphics framework is essentially all indirect rendering, while Windows 2D is all direct rendering.
                        So far as I know, it's 100% direct rendering, now, and has been for some time. EXA, now obsolete, didn't work at all without DRI. Happily, every distribution (I've used in the last two years) seems to have finally worked out how to give out proper permissions to whichever /dev entries X needs without end-user hair-pulling. I understand uid0less X is close, too. ...or, if that depends on KMS, it's a very long way off, since no driver and hardware combination I'm aware of-- yes, I'm sneering at Intel and "Intel" hardware, now --worth using support it.

                        It's kind of a shame, too. I understand PowerVR designs are reasonably nice, at least if you didn't want or need recent OGL implementations.

                        Originally posted by bridgman View Post
                        Not saying that it isn't a driver issue, but I was expecting a Linux vs Linux comparison (eg "brand X Linux HW+drivers have much faster 2D than yours").
                        I imagine Gentoo clocks in noticeably above my Ubuntu workstation, at least on identical hardware, but that's because I can optimize Gentoo properly (using "ricer" optimizations; apparently using gcc compiler flags that were intended to improve performance is somehow bad), and it wouldn't shock me to find out you can still run RHEL on actual i586 hardware. Or maybe i486? Or perhaps they've finally cut off everyone not running at least PPros. The Blob simply gets very little attention and that well after WinCat. I don't think it's my imagination that it's gotten worse since AMD assigned noticeable engineering cycles to the open drivers.

                        Comment


                        • #27
                          Originally posted by rmenessec View Post
                          So far as I know, it's 100% direct rendering, now, and has been for some time. EXA, now obsolete, didn't work at all without DRI.
                          Nope, although I understand why you might think that. 2D acceleration on recent GPUs needs the DRM aka the kernel driver, which is only initialized if you enable DRI, but the 2D rendering still is not direct.

                          With direct rendering the application calls the 3D (or other) driver directly, then the driver checks with the X server (via the DRI extension) to confirm where to draw and then the rest of the drawing happens without going through the X server (although they do go through the kernel driver).

                          For indirect rendering all drawing commands go through the X server and the DRI protocol is not used since the X server calls the drivers itself. The resulting drawing operations may go through the kernel driver but they do not use DRI and they are not "direct rendered".

                          All 2D still goes through the X server, unless you are using a toolkit which draws using OpenGL (in which case the drawing could be direct or indirect).

                          Just curious, if EXA is obsolete what do you think replaced it ? EXA (or UXA, which is essentially the same thing) is the default on pretty much all open drivers today.

                          Originally posted by rmenessec View Post
                          The Blob simply gets very little attention and that well after WinCat. I don't think it's my imagination that it's gotten worse since AMD assigned noticeable engineering cycles to the open drivers.
                          Not sure I get the connection. The open source team are all new hires other than me, and I wasn't working on fglrx beforehand.

                          Comment


                          • #28
                            Originally posted by bridgman View Post
                            All 2D still goes through the X server, unless you are using a toolkit which draws using OpenGL (in which case the drawing could be direct or indirect).
                            That's kind of a complicated picture, innit? Compiz Fusion is quite popular. I'm using it under Ubuntu. GNOME 3's getting compositing. So is KDE 4.6. I assume VDPAU and VA-API are 100% direct...

                            Originally posted by bridgman View Post
                            Just curious, if EXA is obsolete what do you think replaced it ? EXA (or UXA, which is essentially the same thing) is the default on pretty much all open drivers today.
                            Sorry, crossed wires again. At the time I was lurking in #ati, I was told UXA was in fact going to replace EXA. By whom, I don't know. I was also told it was "substantially different". I was wrenching on an Intel IGP ThinkPad at the time, so...

                            Originally posted by bridgman View Post
                            Not sure I get the connection. The open source team are all new hires other than me, and I wasn't working on fglrx beforehand.
                            Yes, but has the fglrx team gotten smaller since you and the other OSS guys were hired? Have they been repurposed to work on WinCat? Are they doing both at once?

                            I'm just saying it seems like LinCat releases have gotten farther and farther apart since more AMD engineering time started going into the OSS code. Maybe it's my imagination, and fglrx releases were always coming too slowly to be useful.

                            Comment


                            • #29
                              Getting back on topic...

                              In an attempt to wrestle this thread back to the original point:

                              Can anyone personally recommend either a maker (relabeler?) or (better yet) a specific SKU of netbook with NVIDIA (preferably) or Intel Ironlake graphics? With an amd64-capable CPU of some kind attached?

                              Support scares, surprisingly good support, overheating issues, nifty accessories available, tips on configuring the synaptics driver to work around touchpad issues on some given machine-- any input would be helpful.

                              I'd especially like to know if it's feasible to jam four whole GiB of RAM into a recent netbook.

                              Comment


                              • #30
                                Originally posted by rmenessec View Post
                                That's kind of a complicated picture, innit? Compiz Fusion is quite popular. I'm using it under Ubuntu. GNOME 3's getting compositing. So is KDE 4.6. I assume VDPAU and VA-API are 100% direct...
                                Compiz also normally uses indirect rendering, so you're actually getting two passes of indirect rendering (one for text, one for compositing). That said, the compositing operations don't happen very frequently (maybe a few hundred times a second) so the overhead of indirect rendering only matters if the server is backlogged on some other operations.

                                Originally posted by rmenessec View Post
                                Yes, but has the fglrx team gotten smaller since you and the other OSS guys were hired? Have they been repurposed to work on WinCat? Are they doing both at once?
                                Nope, I think the Linux-specific part of the fglrx team is now a bit larger than it was before.

                                Originally posted by rmenessec View Post
                                I'm just saying it seems like LinCat releases have gotten farther and farther apart since more AMD engineering time started going into the OSS code. Maybe it's my imagination, and fglrx releases were always coming too slowly to be useful.
                                Definitely imagination. Catalyst for Linux (aka fglrx) releases came out once a month before we had open source drivers, and they come out once a month now.

                                Comment

                                Working...
                                X