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:
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.
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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
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.
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.
0 Likes
Quoting: 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.
0 Likes
Quoting: 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.
Quoting: lucinosQuoting: 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/
?
0 Likes
natewardawg Apr 28, 2017
Quoting: 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.
8 Likes, Who?
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 )
0 Likes
Quoting: operaNot sure if GOL really needs to cover that kind of low level implementation details of graphics drivers.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.
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.
7 Likes, Who?
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 ;)
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 ;)
0 Likes
natewardawg Apr 28, 2017
Quoting: 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.
0 Likes
Quoting: 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.
1 Likes, Who?
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 ^^
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 ^^
0 Likes
Patreon
PayPal
See more from me