Originally posted by davidbepo
View Post
Announcement
Collapse
No announcement yet.
On-Disk Shader Cache Revised For Mesa, Close To Landing
Collapse
X
-
True story. By the way, I never managed to destroy a single SSD at the time writing. Even though I bought some of them used with "only" having 90 % of the write cycles left. Now that one, after a few years, still has > 60 %. For that reason I'd say HDDs will have bad sectors much more earlier than a SSD will fault while writing.
- Likes 5
Comment
-
-
Originally posted by davidbepo View Posti know that and yes i've set journald to not save data, but also if the shaders have to be rebuilt daily the wins are much less
(some of the shader is saved even if rebuilt AFAIK)
Last edited by pal666; 24 January 2017, 08:16 AM.
- Likes 2
Comment
-
Originally posted by davidbepo View Post
constant writes to ssd is not a good idea
the package is updated daily
Using data from millions of drive days in Google datacenters, a new paper offers production lifecycle data on SSD reliability. Surprise! SSDs fail differently than disks - and in a dangerous way. Here's what you need to know.
- Likes 1
Comment
-
Originally posted by pal666 View Postyou can daily write to ssd your shader cache for thousands of years. actually the only point of using ssd is on high-traffic data. otherwise you don't need ssd speed and can use cheaper hdd
- Likes 1
Comment
-
this thread has gone off the rails
to recap what i said so no one confuses
i wont enable it because
1- it wil cause writes to the ssd (i know it wont wear before i buy another or probably never)
2- it wont improve load times much because of the daily recompiles due to mesa git
also thank to the people for the discussion
- Likes 1
Comment
-
-
Originally posted by davidbepo View Postconstant writes to ssd is not a good idea
the package is updated daily
1 Raw_Read_Error_Rate 0x000f 117 110 050 Pre-fail Always - 0/160911102
5 Retired_Block_Count 0x0033 100 100 003 Pre-fail Always - 0
9 Power_On_Hours_and_Msec 0x0032 100 100 000 Old_age Always - 49105h+16m+3
5.920s
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 1004
171 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0
172 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0
174 Unexpect_Power_Loss_Ct 0x0030 000 000 000 Old_age Offline - 113
177 Wear_Range_Delta 0x0000 000 000 000 Old_age Offline - 1
181 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0
182 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
195 ECC_Uncorr_Error_Count 0x001c 117 110 000 Old_age Offline - 0/160911102
196 Reallocated_Event_Count 0x0033 100 100 000 Pre-fail Always - 0
241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 22592
242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 30208
- Likes 1
Comment
-
Originally posted by atomsymbol
About point 2: It's the reason why asked tarceri whether there is a plan to checksum (such as SHA256) the C/C++ source code compiling the shader. That would lower (but not completely remove) the probability of recompiling shaders for people using mesa-git and for updates like mesa-17.x to mesa-17.(x+1).
A viable approach to compute the checksum would be to utilize a source code parser to process the hand-written Mesa C/C++ code.
Comment
Comment