Nouveau - Jul 2011 - [Bug 39010] New: better handling of large pixmaps

https://bugs.freedesktop.org/show_bug.cgi?id=39010

           Summary: better handling of large pixmaps
           Product: xorg
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
        AssignedTo: nouveau at lists.freedesktop.org
        ReportedBy: shiningxc at gmail.com
         QAContact: xorg-team at lists.x.org


Created an attachment (id=48831)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=48831)
possible workaround for 64mb vram cards

Large images in Firefox only show up as black rectangles.

At the same time, the following errors appear in dmesg :
[  590.075369] [drm] nouveau 0000:01:00.0: fail ttm_validate
[  590.075371] [drm] nouveau 0000:01:00.0: validate vram_list
[  590.075374] [drm] nouveau 0000:01:00.0: validate: -12

Test cases :
-
http://geoeyemediaportal.s3.amazonaws.com/assets/images/gallery/ge1/hires/tehran_iran_02_11_10.jpg
- http://xkcd.com/802_large/
-
http://upload.wikimedia.org/wikipedia/commons/5/55/Futuregen_DOE_Concept_art.jpg

References :
- https://bugs.freedesktop.org/show_bug.cgi?id=28763#c15
- http://lists.freedesktop.org/archives/nouveau/2010-February/005125.html

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=39010

Marcin Slusarz <marcin.slusarz at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #48831|application/octet-stream    |text/plain
          mime type|                            |
  Attachment #48831|0                           |1
           is patch|                            |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #1 from Gy?rgy Ball? <ballogy at freestart.hu> 2011-10-26
09:08:56 PDT ---
Thanks for your patch, it solves the problem for me in Firefox with NV17 card
on Arch Linux.

However I sill get 'fail ttm_validate' messages with OpenGL apps (e.g.
quadrapassel, emerillon). When I extend their window's size to the full
screen,
their contents are disappear, and I can see only black and gray rectangles.
There is no problem if I use them only in a small window. (My screen resolution
is 1440 ? 900.)

Could you help me to solve this problem? On the mailing list you mentioned a
libdrm patch to fallback on reloc failures. Could you send me this patch for a
test, please? Or do you know any other workaround?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #2 from Gy?rgy Ball? <ballogy at freestart.hu> 2011-10-26
20:03:23 PDT ---
Unfortunately, your patch extremely slows down XVideo performance.

I think we need to find another solution to avoid memory flush.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #3 from Gy?rgy Ball? <ballogy at freestart.hu> 2011-10-30
00:40:40 PDT ---
Created attachment 52905
  --> https://bugs.freedesktop.org/attachment.cgi?id=52905
exa: set max dimensions based on available VRAM

I found a solution!

Since the VRAM size could vary inside each series of cards (e.g. NV10 cards may
have 32, 64 or 128 MB VRAM), it would better to set max dimensions based on
available VRAM instead of card series.

My proposed patch ensures that we always have enough space in VRAM to process
images. It fixes memory flush on 64 MB cards, and adds back exa support for
cards that have 32 MB or less memory (with a minimal 8 MB VRAM).

I tested this patch only on NV17 with 64 MB VRAM.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #4 from Andrew Randrianasulu <randrik at mail.ru> 2011-10-30
01:56:11 PDT ---
(In reply to comment #3)
> Created attachment 52905 [details] [review]
> exa: set max dimensions based on available VRAM
> 
> I found a solution!
> 
> Since the VRAM size could vary inside each series of cards (e.g. NV10 cards
may
> have 32, 64 or 128 MB VRAM), it would better to set max dimensions based on
> available VRAM instead of card series.
> 
> My proposed patch ensures that we always have enough space in VRAM to
process
> images. It fixes memory flush on 64 MB cards, and adds back exa support for
> cards that have 32 MB or less memory (with a minimal 8 MB VRAM).
> 
> I tested this patch only on NV17 with 64 MB VRAM.
Hm .... but those limits may also reflect some hw (family-specific) limits?
What about more complex check? Pseudo : 

if card_family == NV10 
{ if vram >= nv_10_min_ram : exa->maxX= 4096; else exa->maxX = 2046; } 
 elseif card_family == NV50
{ if vram >= nv_50_min_vram : exa->maxX = 8190; else exa->maxX = 4096;
}
exa->maxX =  2046
endif

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #5 from Andrew Randrianasulu <randrik at mail.ru> 2011-10-30
02:02:30 PDT ---
(In reply to comment #3)
> Created attachment 52905 [details] [review]
> exa: set max dimensions based on available VRAM
> 
> I found a solution!
> 
> Since the VRAM size could vary inside each series of cards (e.g. NV10 cards
may
> have 32, 64 or 128 MB VRAM), it would better to set max dimensions based on
> available VRAM instead of card series.
> 
> My proposed patch ensures that we always have enough space in VRAM to
process
> images. It fixes memory flush on 64 MB cards, and adds back exa support for
> cards that have 32 MB or less memory (with a minimal 8 MB VRAM).
> 
> I tested this patch only on NV17 with 64 MB VRAM.
And anyway ... shouldn't big pixmaps in case of vram shortage just be placed
in
GART, and used from it? (sure, xvideo will be slower ...special hint for xv
pixmaps? can't remember if its already there .....)

I have hacked up 2.6.38 kernel (frambuffer default bpp to 8, not 32 -> 5 to 1
mb of vram saved) on machine with tnt2 vanta - 8mb/AGP - it works ... even as
OpenGL hw renderer, i just need to lower resolution back to 640x480x32 for good
Quake1.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=39010

Gy?rgy Ball? <ballogy at freestart.hu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52905|0                           |1
        is obsolete|                            |

--- Comment #6 from Gy?rgy Ball? <ballogy at freestart.hu> 2012-09-09
17:43:40 UTC ---
Created attachment 66885
  --> https://bugs.freedesktop.org/attachment.cgi?id=66885
exa: set max dimensions based on available VRAM

I updated the patch for the current git master.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #7 from Gy?rgy Ball? <ballogy at freestart.hu> ---
It is still a problem with the following components:
- linux 3.10.7
- libdrm 2.4.46
- xf86-video-nouveau 1.0.9

Could someone review the patch from the nouveau team?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130820/2e94d12f/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #8 from Ilia Mirkin <imirkin at alum.mit.edu> ---
What's with the weird non-power-of-2 sizes?

Wouldn't it be better to have a target number of pixmaps to fit in vram, or
perhaps a percentage of vram that you're willing to take up with a single
pixmap? There are lots of cards with all sorts of quantities of memory (e.g.
there are 8800's with 320MB of RAM).

So once you determine a percentage, just have a list of sizes like

sizes = [8192, 4096, 2048]
for size in sizes:
  if size * size * 4 < memory * 0.1:
    return size
return 1024

(This is an example where I assume RGBA pixmaps, up to 10% of vram, but I
picked that at random... maybe other percentages would be more reasonable...
play around with the numbers. It certainly seems that we'd never want to
allow
a pixmap that's bigger than VRAM, at the very least, which with current
code,
there could be, if there were nv10+ with < 64MB of vram, which I'm pretty
sure
I've seen with at least NV1A with 32M of stolen ram.)

[Note: please don't take this as an endorsement of the approach. In fact, I
thought TTM should be able to handle all that, but apparently not. This is just
a comment on improving your patch, irrespective of the overall approach.]

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130820/930f12fa/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #9 from Gy?rgy Ball? <ballogy at freestart.hu> ---
I'm not a developer, so I don't know what would be the best solution.
With the
current driver on NV17 with 64 MB VRAM, if I open a picture in Firefox that
larger than 2047px?2047px, it causes 'fail ttm_validate' errors. If I
reduce
the max. pixmap size from 4096?4096 to 2046?2046, it solves the problem.

I don't have any other NVIDIA hardware to test my patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130820/ef095b60/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #10 from Ilia Mirkin <imirkin at alum.mit.edu> ---
So a 2046x2046 image works but a 2047x2047 image doesn't? That's
awefully
specific... and weird. I'll try to remember to test this all out on my NV18
with 64M of VRAM and see what happens.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130820/bf3fe8e5/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=39010

--- Comment #11 from Tobias Klausmann <tobias.klausmann at mni.thm.de> ---
Is this still a problem with the newest xf86-video-nouveau?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150125/0d3a209f/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=39010

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #12 from Martin Peres <martin.peres at free.fr> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/19.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/b5f30102/attachment.html>