[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mesa3d-dev
Subject:    Re: [Mesa3d-dev] Blit support for r300
From:       Corbin Simpson <mostawesomedude () gmail ! com>
Date:       2009-10-23 18:05:23
Message-ID: 4AE1F063.3090600 () gmail ! com
[Download RAW message or body]

On 10/23/2009 10:59 AM, Joakim Sindholt wrote:
> On Fri, 2009-10-23 at 11:17 -0400, Alex Deucher wrote:
>> On Fri, Oct 23, 2009 at 2:37 AM, Maciej Cencora <m.cencora@gmail.com> wrote:
>>> Hi,
>>>
>>> as you may already know r300 classic driver is in pretty good shape these
>>> days, but there's one thing that causes major slowdowns in many games: lack of
>>> hardware accelerated blit operation.
>>> Currently all glCopyTex[Sub]Image operations are done through span functions
>>> which is slow as hell.
>>> We could use the hw blitter unit, but using it causes stalls because of the
>>> 2D/3D mode switch.
>>> I was wondering how this could be fixed and I got this crazy idea of porting
>>> the everything-is-texture concept from gallium to classic mesa. Actually not
>>> all of it, just the pieces that make the renderbuffers look like textures for
>>> the driver.
>>
>> Shouldn't be too hard to implement using the 3D engine.  We could
>> write a generic radeon_blit.c modules and then add asic specific
>> functions to the vtbl to actually do the blit.  The 3D engine will
>> also get better memory throughput on newer chips than the 2D engine,
>> so that's another advantage.
>>
>> Alex
> 
> Does this actually fix our problem in Gallium though? surface_copy is
> supposed to be able to blit any area to any area. There's no format
> change involved and thus it expects that we will copy any amount of data
> in any format. Sure we can implement a blitter using the 3D engine that
> just copies a texture, but what about the cases where we get a texture
> format the 3D engine doesn't recognize?

We already had that discussion last week, and the end result is that
r300g and r600g just don't have surface_fill or surface_copy, the API is
officially okay with that, and the parts of code in state trackers that
test for it should probably have some better fallback paths. In
particular util_surface_fill and util_surface_copy are memset and memcpy
and should only be last-resort fallbacks.

In classic Mesa this is actually less of a problem because you will
never get a request to copy or fill buffers you can't render to. On the
other hand, I'm not committing to classic r300 any longer, and I already
solved this problem for Gallium, so I really don't care if people want
to spend their time adding yet more things to classic.

~ 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
[prev in list] [next in list] [prev in thread] [next in thread]