| Summary: | mesa REALLY needs to go on a diet. | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Carsten Haitzler <raster> |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | barbieri, cmarcelo, kenneth |
| Version: | 9.1 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
valgrind massif trace of memory usage of a very simple test program
newer mesa 9.1.2 memroy dump |
||
|
Description
Carsten Haitzler
2013-06-04 10:50:16 UTC
Created attachment 80351 [details]
newer mesa 9.1.2 memroy dump
still uses a vast amount of memory even with 9.1.2.
and on a newer mesa 9.1.2 - also still uses huge amounts of memory. http://www.enlightenment.org/ss/e-51af4c975faac9.57775536.png With the latest Mesa, OpenGL ES 2.0/3.0 won't create a swrast context, eliminating the large red block in your graph. I measured 18MB of savings in one program. OpenGL 3.1 (the non-legacy version) also skips this, but it's unfortunately still necessary for legacy desktop GL. I'm scratching my head, wondering why it would be required to alloc this blob for desktop gl? is it for software fallbacks of some kind not supported by mesa hw accel infra? why would it need it? i'm really curious. if it needs memory for sw fallbacks, can't it alloc on-demand? (ie when operation requires such memory... and 18m is a vast chunk of memory!). if its a few 10's of kb... sure - i can see why no one bothered, but this order of magnitude of memory usage should be allocated when needed then freed again when not needed... ? if i know what it is that triggers the need then i know what to avoid in the api so the alloc never happens. The swrast context is a kitchen sink for all of the fixed-function "stuff." This is both software fallbacks and fixed-function TNL. The problem with on-demand allocation is that I don't think we'd know that we need to allocate it until draw-time... which would cause a rendering hiccup. Almost every application that's using a classic GL context will hit one of these paths at some point. :( I'm not saying we can't do anything. I'm just saying it will be a lot of work, and it's really low priority for us. well if the hiccup happens only for the first frame that needs it... then does it much matter? is there anything i can do to convince mesa not to eat up all this memory? my usage is entirely glsl - no fixed function usage at all. in fact the codebase is explicitly designed around using the glesv2 "subset" of desktop gl (yes i know its not a proper subset - there are a few exceptions in dark corners) as it actually just switches between glx/gl and glesv2 depending on build mode. i know you can say "then just use glesv2" - problem is that 99% of the time this simply isn't even there, though it is an option to build mesa that way. what i'd love, nay need, is some gl context incantation i can say that says "away with ye demons of evil memory allocation. i need ye not!" (and then some crazy hand waving, flashes of light and puffs of smoke). :) (In reply to comment #6) > well if the hiccup happens only for the first frame that needs it... then > does it much matter? Perhaps not. We do get complaints about that sort of thing, but it's usually more the state-based shader recompile hiccups. We just don't have anyone to do the work. > is there anything i can do to convince mesa not to eat up all this memory? > my usage is entirely glsl - no fixed function usage at all. in fact the > codebase is explicitly designed around using the glesv2 "subset" of desktop > gl (yes i know its not a proper subset - there are a few exceptions in dark > corners) as it actually just switches between glx/gl and glesv2 depending on > build mode. i know you can say "then just use glesv2" - problem is that 99% > of the time this simply isn't even there, though it is an option to build > mesa that way. > > what i'd love, nay need, is some gl context incantation i can say that says > "away with ye demons of evil memory allocation. i need ye not!" (and then > some crazy hand waving, flashes of light and puffs of smoke). :) There is. Ask for a 3.1 context or a 3.0 "forward compatible" context. That will give you what you want on all the drivers that support at least OpenGL 3.0. That same mechanism will also work on closed-source drivers, so you won't have any Mesa specific code to worry about maintaining. |
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.
