Blit support for r300

[Maciej Cencora]

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.

Brian, what do you think about this idea? Is it feasible and worth doing?
Maybe you have better ideas how to resolve this issue?

Regards,
Maciej

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Ian Romanick-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Maciej Cencora wrote:

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

The other way to do it is "everything is a buffer object".  That's how
this sort of thing is handled in the i915 and i965 drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrhXkgACgkQX1gOwKyEAw/UGgCgmt5JhqDersavJ+jq9pCwyQqH
kuYAnj+p1NpZ2da0YMbfsq2OLOgvyv5u
=yALF
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Roland Scheidegger-4]

On 23.10.2009 08:37, Maciej Cencora 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.
The same is true for r100/r200...

> 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.
A long time ago I implemented this as a hack for r200 (just blit
directly to the texture in vram, so never touching the backup texture in
system memory). Worked quite well in practice (good enough for doom3
special effects). I didn't notice any obvious slowdowns due to 2d/3d
sync issues (though maybe I didn't do any syncs...).

> 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.
You could probably just try to hack up a blit using 3d engine? Though of
course lots of setup would be needed. Nice thing about not using blitter
 (apart from potential performance issues) is of course that you can
also support format conversion for free.

>
> Brian, what do you think about this idea? Is it feasible and worth doing?
> Maybe you have better ideas how to resolve this issue?
Not sure what Brian's opinion on that is, but I'm not sure if there's
really much point in trying to port over half of gallium to classic
mesa. Looks to me like time might be better spent working on gallium
drivers instead...

Roland

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

Roland Scheidegger wrote:

> On 23.10.2009 08:37, Maciej Cencora 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.
> The same is true for r100/r200...
>
>> 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.
> A long time ago I implemented this as a hack for r200 (just blit
> directly to the texture in vram, so never touching the backup texture in
> system memory). Worked quite well in practice (good enough for doom3
> special effects). I didn't notice any obvious slowdowns due to 2d/3d
> sync issues (though maybe I didn't do any syncs...).
>
>> 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.
> You could probably just try to hack up a blit using 3d engine? Though of
> course lots of setup would be needed. Nice thing about not using blitter
>  (apart from potential performance issues) is of course that you can
> also support format conversion for free.
>
>> Brian, what do you think about this idea? Is it feasible and worth doing?
>> Maybe you have better ideas how to resolve this issue?
> Not sure what Brian's opinion on that is, but I'm not sure if there's
> really much point in trying to port over half of gallium to classic
> mesa. Looks to me like time might be better spent working on gallium
> drivers instead...

Yeah, I'd probably opt to work on the gallium driver rather than spend
a lot of time and effort on the original driver.

-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
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Alex Deucher]

On Fri, Oct 23, 2009 at 2:37 AM, Maciej Cencora <m.cencora@...> 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

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Joakim Sindholt]

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


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Corbin Simpson]

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@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev