Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Flattr, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

Mesa 17.1 will use a set 1GB size for the shader cache

By - | Views: 17,942
The Mesa developers have been plugging away to get Mesa 17.1 into shape for release, one feature in particular has seen a lot of attention: the shader cache. It will no longer use a percentage of available disk space.

The Mesa developer Timothy Arceri said:
QuoteThe more I think about it the more this seems like a bad idea. When we were deleting old cache dirs this wasn't so bad as it was unlikely we would ever hit the actual limit before things
were cleaned up. Now that we only start cleaning up old cache items once the limit is reached the a percentage based max cache limit is more risky.

For the inital release of shader cache I think its better to stick to a more conservative cache limit, at least until we have some way of cleaning up the cache more aggressively.

Going by the commit itself, it will be sticking to a 1GB size for the cache now. It's already landed in Mesa git, so it should be in the 17.1 release.

Mesa 17.1 is due for release on May 5th next month, as detailed here. Article taken from GamingOnLinux.com.
Tags: Drivers, Mesa
5 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
13 comments
Page: 1/2»
  Go to:

opera 28 Apr, 2017
Not sure if GOL really needs to cover that kind of low level implementation details of graphics drivers.
I agree that the scope of driver functions is very interesting but the actual size of particular driver cache is a little too deep from my point of view.
lucinos 28 Apr, 2017
operaNot sure if GOL really needs to cover that kind of low level implementation details of graphics drivers.
I agree that the scope of driver functions is very interesting but the actual size of particular driver cache is a little too deep from my point of view.

In principle I agree with you, but...

I am thinking that probably as long as this kind of news are not too great of percentage of total news, it is more simple and better to not doing such filter so _really_ interesting news will not go unnoticed. On the other hand if this is getting out of hand I would say news should be filtered more.
Guest 28 Apr, 2017
operaNot sure if GOL really needs to cover that kind of low level implementation details of graphics drivers.
I agree that the scope of driver functions is very interesting but the actual size of particular driver cache is a little too deep from my point of view.

lucinos
operaNot sure if GOL really needs to cover that kind of low level implementation details of graphics drivers.
I agree that the scope of driver functions is very interesting but the actual size of particular driver cache is a little too deep from my point of view.

In principle I agree with you, but...

I am thinking that probably as long as this kind of news are not too great of percentage of total news, it is more simple and better to not doing such filter so _really_ interesting news will not go unnoticed. On the other hand if this is getting out of hand I would say news should be filtered more.

Then perhaps the deeper more technial stuff should go on https://www.lifeonlinux.com/

?
natewardawg 28 Apr, 2017
operaNot sure if GOL really needs to cover that kind of low level implementation details of graphics drivers.
I agree that the scope of driver functions is very interesting but the actual size of particular driver cache is a little too deep from my point of view.

I personally really like having these tid bits. I do agree that I wouldn't want these types of news to be the main thing I read about, but I think Liam does a good job of sprinkling them in without it becoming overwhelming.
Guest 28 Apr, 2017
I kind of like the idea of the two sites merging and when you click on technical news it sort of swipes to LOL and Gaming news swipes to GOL ( but im being overly optimistic here and probably just day dreaming )
Liam Dawe 28 Apr, 2017
operaNot sure if GOL really needs to cover that kind of low level implementation details of graphics drivers.
I agree that the scope of driver functions is very interesting but the actual size of particular driver cache is a little too deep from my point of view.
We have covered stuff like this plenty of times in the past and you're the first to make a complaint about it. Usually, people appreciate it.
FrankyFire 28 Apr, 2017
I appreciate it as well. That's actually a topic we're discussing in my lectures, because it's quite tough to find a fast and easy (regarding the gate expense) way of realising the cleaning of a cache. Our mentor said, that usually use 3 different ways of doing that:
1. Random
2. Deleting at the end (like a stack)
3. (And most common) by timetable, where the last use of the address is stored in an extra set of bits. If the cache is full, the oldest address will be removed. Or if a predefined time of last use has been expired.

As you may see, this is a really interesting topic for some. Especially because Linux users are usually power users as well. If you are not interested, you don't need to read that. Only thing I could criticise is the lack of an explanation. But as this is a hobby project (afaik), I don't bother.

Thanks to Liam for that article, made me sign up to GOL ;)
natewardawg 28 Apr, 2017
FrankyFire2. Deleting at the end (like a stack)
3. (And most common) by timetable, where the last use of the address is stored in an extra set of bits. If the cache is full, the oldest address will be removed. Or if a predefined time of last use has been expired.

I almost always use a combination of 2 and 3. I usually have a separate list that references the files and stores the epoch time of the last access to it. If a cache file is either added or "touched" I move it to the top of the list. This way there's no need to recurse each file and check for oldest dates. I get it all immediately from a fairly small file. The files at the very bottom of the list will be the least recently used and the ones at the top will be the most recently used. So if the cache is full I just start deleting off the bottom of the list. I can also check the timestamp and if the last access has exceeded a period of time I can just nuke it.

Are you aware of any instance where the random method would be the ideal for deleting cached files? I'm trying to think of something but am drawing a blank.
Purple Library Guy 28 Apr, 2017
meggermanI kind of like the idea of the two sites merging and when you click on technical news it sort of swipes to LOL and Gaming news swipes to GOL ( but im being overly optimistic here and probably just day dreaming )
I had not actually assumed Life on Linux was supposed to be a technically-oriented site. One reason I don't bother looking at Linuxtoday much any more is that it's practically all about business-technical stuff which is of no interest to a desktop user. I was kind of hoping that, since it's split off from a gaming site, and Linux gamers are mostly Linux desktop users, Life on Linux would be a bit more people-oriented and desktop-oriented than some of what's out there.
If anything, I would think the technical underpinnings of graphics-related stuff would be more appropriate to a gaming site than a general-interest Linux site.
Creak 28 Apr, 2017
View PC info
  • Supporter Plus
Right now I'm not sure there's enough game-only news on Linux, but as time goes on, if the amount of game news increases significantly, maybe it would be nice to have these technical news on LifeOnLinux...

LifeOnLinux is like the newer, better Phoronix (or at least I wish that it is what it would become ;) ), and this is the kind of news that Phoronix covers.

But all in all, on GoL or on LoL, I don't really care, I'm following both (though I need more and more a Google+ page for LoL :/ ) and as long as the news is on one of these websites, I'm happy ^^
While you're here, please consider supporting GamingOnLinux on Patreon, Liberapay or Paypal. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!