Corbin Simpson wrote: > 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 <[email protected]> >>>> 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.
For surface_copy() the src and dst surfaces will always be of the same format. >> 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. It's important to understand when/where surface_copy() and surface_fill() are used: Currently, surface_fill() is only used for the util_clear() utility/fallback function. Most drivers should do something smarter for clear(), I think. surface_copy() is mainly used to copy mipmap levels from one texture to another, glCopyTex[Sub]Image() and glCopyPixels(). I believe we'll often be flushing the 3D pipe before doing these things anyway. > 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. Sure. I totally understand the desire to avoid using the blitter. I'm just trying to clarify those two functions. If surface_copy() is always done with 3D rendering, it has to be able to cope with any src texture format as a possible destination (ex: for mipmap level copying). In the state tracker we could avoid calling surface_copy() when the driver doesn't support rendering to the dest format. We'd probably fall back to map/memcpy/unmap but that's what util_surface_copy() does already. So it's just a matter of who calls it. > 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. -Brian ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
