<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - better handling of large pixmaps" href="https://bugs.freedesktop.org/show_bug.cgi?id=39010#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - better handling of large pixmaps" href="https://bugs.freedesktop.org/show_bug.cgi?id=39010">bug 39010</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>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.]</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>