Make it possible to restrict texture size of GUI panel button pixmaps#2982
Conversation
|
Great PR! Please pay attention to the following items before merging: Files matching
This is an automatically generated QA checklist based on modified files. |
|
I am trying to at least keep (actually already: restore) some way of running on RPi3 (at ~3-5fps it still may have its use), even if some features will no longer be available in full quality. Currently it fails when zooming in while showing the DSO texture loading bar. It seems now it barely loaded again (I saw M42, but it crashed again on further zoom in). Logfile says nothing, though. Not loading DSO and just using icons would probably be OK (seems stable). Mars renders, but the Moon has no surface rendering. Equirectangular projection with "spherical" landscapes works. If this PR reduces texture memory used for the actual buttons, even just a few kB, I approve it. Maybe change name to But I have severely not enough time for testing all platforms with the many GLSL updates (although OTOH I welcome them!). |
|
The main question is: does this patch change anything usefully? If the change is not noticeable, this would be just a useless complication. |
|
Also, it would be useful to have the output of |
|
I wonder about texture compression. The RPi supports ETC1 compression, but what does it take to activate this? I just converted all DSO textures to 64x64, and it runs well again. Better blurred than crash, IMO. Maybe we can configure another (config.ini and/or GUI-available?) switch for "limit texture use"? RPi3_glxinfo-l.txt |
So this is why the Moon is not rendered: our texture is 4096×2048. May be worth it to resize each texture being loaded if it doesn't fit OpenGL limits.
This is a lot. Do DSO really take so much to hit this limit? |
Where are they stored? What's their initial size? Also, the log doesn't appear to say that the crash is due to lack of memory. How did you come to this conclusion? |
Yes, such test and auto-resize should be added in any case! 2048 was the max texture size ever used just for that reason. (And as said, this is why old_style landscapes were required and are still useful.)
I am not sure if this number is correctly reported. The total RAM of this device is 1GB, and raspi-config is used to set a part of this memory for GPU use (64/128/256MB). The documentation is unclear, though, about the right split. Some say the new driver does not use it (set to 64MB), but now I tried 256MB. Maybe this is the total of remaining memory, and the 256MB is even lost... |
nebulae/default/*.png
The program hangs for a minute, then exits. dmesg indicates memory issues (The exact wording comes from the VC4 driver. I think there are no gl_error messages available on this platform. ) |
How does it work currently? You load large button textures and show them (usually) smaller? Why not make the actual textures the same size as later used on the screen? Or do you fight the rare occasion when a Stellarium window is moved between different screens of different scalings? |
This sounds like out of system RAM, rather than VRAM. Namely, heavy swapping (which looks like a hang to the user), and then process termination. Does dmesg say something like "Out of memory: Killed process ..."?
I load large textures, and resize them to the configured scale. Then I render them as usual, scaling according to current scale factor as needed.
Exactly. Stellarium is not always run in fullscreen mode. And when it's windowed, it's not really rare to move the window around. If you want to use one particular scaling factor you want, and don't care about differences between screens, just put this value in the config. This is the purpose of this PR, after all. |
|
The texture decimation (#3009) seemed to have remedied the basic problem around RPi3. Can you estimate how many MB this patch here would save additionally? The RPi3 has no separate texture memory, just 1GB of system memory for everything. Assume no screen scaling, just FullHD screen (at most) for the RPi3. If this is a few MB only, we can probably close this if you think it just complicates matters. If it's more, we should use it. |
About 10 MiB. Maybe less. |
|
Hmm, that's just the size of about 3-5 large DSO textures. Still it is "something", so if sufficiently commented, I still would use it. |
gzotti
left a comment
gzotti
left a comment
There was a problem hiding this comment.
I think conserving memory has its merits on limited systems, so yes, Approved!
|
Hello @10110111! The fix has been merged into source code and you may test it via building Stellarium from source code or wait the weekly development snapshot... |
alex-w
added
state: published
|
Hello @10110111! Please check the fresh version (development snapshot) of Stellarium: |
alex-w
removed
the
state: published
|
Hello @10110111! Please check the latest stable version of Stellarium: |
3 participants
A few times @gzotti complained that the new high-resolution pixmaps used for GUI panel buttons make performance worse on low-spec systems like Raspberry or something like that. This patch introduces a config file setting,
gui/pixmaps_scale, which can vary from 1 to 5, to reduce the pixmaps loaded from resources to corresponding scale factor.E.g., on a machine with a low-DPI monitor, where scale factor higher than 100% is not supposed to be useful, we can set this setting to
1, and avoid using excessive VRAM for 500%-scale textures. Or, if the scaling factor of the monitor is higher than 100% but much lower than 500%, we can set that exact scaling factor as the maximum scale of the pixmaps, thus reducing VRAM use.I'm not sure if this 500% increase of texture size really influences performance, but, since @gzotti complained more than once, I propose this patch, which might help.