On Thu, Oct 15, 2009 at 10:58 PM, Younes Manton <[email protected]> wrote: > On Thu, Oct 15, 2009 at 8:54 PM, Corbin Simpson > <[email protected]> wrote: >> URL: >> http://cgit.freedesktop.org/~csimpson/mesa/log/?h=gallium-blitter >> >> So, with r600g right around the corner, I'd like to do something about >> this blitter/no blitter thing. > > Just wondering, how can you get hardware clear/copy on R600 if the 3D > engine can't sample and render to a particular format? Are you doomed > to a software fallback for these? Hopefully no relatively common > format is in that category.
You can always use 1 byte src/dst formats and implement memcpy using the 3D engine. > >> This patch series contains one new getparam, PIPE_CAP_BLITTER, and a >> proposed ABI change to accompany it. >> >> surface_copy and surface_fill are proposed to have a way of indicating >> whether or not they successfully performed the fill/blit. It is up to >> the state tracker to determine whether or not to rely on these functions. >> >> Issues: >> - Should surface_copy and surface_fill return boolean instead of void? >> With this patchset, they'll return FALSE if they fail, and always return >> FALSE if PIPE_CAP_BLITTER isn't set. >> - Instead, should surface_copy and surface_fill simply be allowed to be >> NULL if PIPE_CAP_BLITTER is set? State tracker could continue to assume >> that, if present, surface_copy and surface_fill behave as expected and >> never fail. > > I prefer NULL, at least you know right away if you try to call and it > isn't available, vs forgetting to check the return value and having to > track it down. However I think right there's a mix of both conventions > in use right now... > >> - Should clear be included with these two? I don't think any drivers are >> doing anything with clear except wiring it up to util_clear... > > Better to let them keep the option for flexibility's sake IMO, > especially if it doesn't require much maintenance. If someone ever > needs to do something different here it's an easy job. > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
