On 10/13/2009 08:34 AM, Brian Paul wrote: > José Fonseca wrote: >> On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: >>> Module: Mesa >>> Branch: master >>> Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 >>> URL: >>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 >>> >>> >>> Author: Corbin Simpson <mostawesomed...@gmail.com> >>> Date: Mon Oct 12 20:47:00 2009 -0700 >>> >>> r300g: Fallback on surfaces we can't render to or from. >>> >>> Still not sure why st keeps handing down things we can't render to. >> >> Corbin, >> >> This is a problem of the Mesa state tracker and most co-statetrackers >> that sit on top of it. It's better than it was before but there are >> still a few places where it uses formats without querying the driver. A >> typical problem are PIPE_FORMAT_x -> Mesa visual translation. I had to >> solve this in the WGL state tracker, but it would be nice if we had >> shared code for that in src/mesa/state_tracker . > > This is just happening with surface_copy() and surface_fill(), right? > > I think the assumption was that if the driver can create a surface in > format X, then it can copy and fill regions in format X by one means or > another (and not necessarily by 3D rendering).
Well, yes and no. Byte-for-byte copies are pretty easy with a fallback, and I could probably get those to be pretty speedy with BO moves and a custom libdrm hook. Shifting formats is iffy though, and at that point we're talking about turning on the blitter. > Corbin, it looks like you're using quads/points to do the copy/fill. > Can't some sort of blit be used instead? And here's where we get fun. Turning on the blitter is non-trivial in r300/r500. We have to flush, send a 2D-only command packet with the fill/copy, and then flush again when we go back to 3D. This is messy and painful. Kernel-side, the kernel actually has to idle most of the card to do the switch. If we're doing any serious 3D work, anybody doing glClear() at the beginning of their frame is incurring a massive penalty. We could turn on the blitter, but I'd rather see this handled with PIPE_CAP_BLITTER or something similar, because r600g will be blitter-less and completely dependent on its 3D engine, and I'd like to be prepared sooner rather than later. Aside: We use points for fills because fglrx uses points for clears/fills, and we seem to be getting really good speeds that way. Silly, but effective. ~ C. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
