Bug 19366

Created attachment 21625 [details]
xorg.conf

Created attachment 21627 [details]
Xorg.0.log

Created attachment 21628 [details]
glxinfo

Created attachment 21629 [details]
lspci

this prob is most come from glCopyTexSubImage[1,2]D are done in software path.

  208      100.000  r300_dri.so              _swrast_copy_texsubimage2d
19        0.0091  r300_dri.so              read_color_image
  197127   99.9792  r300_dri.so              _swrast_read_rgba_span
  19        0.0096  r300_dri.so              read_color_image [self]
  16        0.0081  r300_dri.so              __i686.get_pc_thunk.bx
  3         0.0015  r300_dri.so              radeonSpanRenderFinish
  1        5.1e-04  r300_dri.so              radeonReadRGBASpan_ARGB8888_SSE
  1        5.1e-04  r300_dri.so              _mesa_bytes_per_pixel
  1        5.1e-04  libc-2.9.so              malloc
-------------------------------------------------------------------------------
  3         0.0015  r300_dri.so              _swrast_copy_texsubimage2d
  197127   99.9985  r300_dri.so              read_color_image
51        0.0244  r300_dri.so              _swrast_read_rgba_span
  196980   99.9138  r300_dri.so              _fini
  96        0.0487  r300_dri.so              radeonReadRGBASpan_ARGB8888_SSE
  51        0.0259  r300_dri.so              _swrast_read_rgba_span [self]
  20        0.0101  r300_dri.so              _generic_read_RGBA_span_BGRA8888_REV_SSE
  3         0.0015  r300_dri.so              __i686.get_pc_thunk.bx
-------------------------------------------------------------------------------
  20        0.0102  r300_dri.so              _swrast_read_rgba_span
  196981   99.9898  r300_dri.so              _fini
197001   94.2413  r300_dri.so              _generic_read_RGBA_span_BGRA8888_REV_SSE
  197001   100.000  r300_dri.so              _generic_read_RGBA_span_BGRA8888_REV_SSE [self]

(In reply to comment #5)
> this prob is most come from glCopyTexSubImage[1,2]D are done in software path.


can you please be more clear how we can solve the problem?

(In reply to comment #6)
> can you please be more clear how we can solve the problem?
> 
It's a software limitation at the moment. Someone needs to teach the driver how to avoid this software fallback.

(In reply to comment #7)
> (In reply to comment #6)
> > can you please be more clear how we can solve the problem?
> > 
> It's a software limitation at the moment. Someone needs to teach the driver how
> to avoid this software fallback.

The big problem here is this really requires a real memory manager. Once upon a time I've written a patch (for r200 not r300 but it doesn't matter it's exactly the same problem) which avoids the fallback (by just doing a gpu blit to the vram copy of the texture). But it's very incorrect (though working for doom3 special effects...) since the vram copy of the texture can be evicted at any time and then you'd reuse the old, now outdated copy which mesa has in system ram.
And btw it's quite likely the app doesn't even want to use glCopyTexSubImage but rather FBO's (to avoid the copy entirely), which can't be supported without a memory manager neither.

I'm working on hw blit support that will fix this problem.
Check out my r300-blit branch here http://cgit.freedesktop.org/~osiris/mesa
currently it's fixed for r500 GPUs, support for r300 and r400 should follow soon.
I've checked the openarena with my patches and it is pretty smooth.

Blit branch has been merged to master.

(In reply to comment #10)
> Blit branch has been merged to master.

Is there any chance to enable it also on non KMS?

*** Bug 28226 has been marked as a duplicate of this bug. ***