Bug 19366 - [Ubuntu][Openarena 0.8.0]: When enabled BLOOM option, the FPS drops to 1 and system response is very less
Summary: [Ubuntu][Openarena 0.8.0]: When enabled BLOOM option, the FPS drops to 1 and ...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: 7.2
Hardware: x86 (IA32) other
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 28226 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-02 02:50 UTC by Sunil Mekathotti
Modified: 2010-05-28 02:11 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

Attachments
xorg.conf (1.50 KB, text/plain)
2009-01-02 02:52 UTC, Sunil Mekathotti 		Details
Xorg.0.log (81.06 KB, text/plain)
2009-01-02 02:52 UTC, Sunil Mekathotti 		Details
glxinfo (4.27 KB, text/plain)
2009-01-02 02:53 UTC, Sunil Mekathotti 		Details
lspci (1.23 KB, text/plain)
2009-01-02 02:53 UTC, Sunil Mekathotti 		Details
View All

Description Sunil Mekathotti 2009-01-02 02:50:43 UTC 
Details of the X-stack:
----------------------

mesa/drm:           master (git)     29-DEC                            
mesa/mesa :        7.2                                             
xorg/xserver:        1.5.2                                               
xorg/xf86-video-ati: master(git)      29-DEC                             
xorg/driver/xf86-input-keyboard - 1.3.0                  
xorg/driver/xf86-input-mouse-1.3.0 


 Problem:
---------
When enabled BLOOM option in SETUP

 the FPS drops to 1 and system and system response is very less.
Comment 1 Sunil Mekathotti 2009-01-02 02:52:02 UTC 
Created attachment 21625 [details]
xorg.conf
Comment 2 Sunil Mekathotti 2009-01-02 02:52:41 UTC 
Created attachment 21627 [details]
Xorg.0.log
Comment 3 Sunil Mekathotti 2009-01-02 02:53:22 UTC 
Created attachment 21628 [details]
glxinfo
Comment 4 Sunil Mekathotti 2009-01-02 02:53:56 UTC 
Created attachment 21629 [details]
lspci
Comment 5 Shunichi Fuji 2009-01-02 20:18:00 UTC 
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]
Comment 6 Sunil Mekathotti 2009-01-23 02:29:11 UTC 
(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?
Comment 7 Ben Gamari 2009-01-25 12:12:07 UTC 
(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.
Comment 8 Roland Scheidegger 2009-01-26 06:17:54 UTC 
(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.
Comment 9 Maciej Cencora 2009-11-11 05:09:09 UTC 
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.
Comment 10 Maciej Cencora 2009-12-19 06:52:54 UTC 
Blit branch has been merged to master.
Comment 11 Fabio Pedretti 2009-12-21 02:25:58 UTC 
(In reply to comment #10)
> Blit branch has been merged to master.

Is there any chance to enable it also on non KMS?
Comment 12 samit vats 2010-05-28 02:11:18 UTC 
*** Bug 28226 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.