Recommendations for a netbook with 3D accelerator?

[Kano]

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?

[rmenessec]

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.

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.)

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.

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.

[rmenessec]

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.

[bridgman]

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.

[bridgman]

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").

[rmenessec]

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.

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.

[bridgman]

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.

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.

[rmenessec]

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...

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...

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.

[rmenessec]

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.

[bridgman]

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.

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.

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.