Originally posted by dungeon
View Post
Announcement
Collapse
No announcement yet.
New Mesa Patch To Improve CPU-Bound Applications
Collapse
X
-
Originally posted by nanonyme View PostYou could probably get some dev bisect for you if you send them your computer. More seriously, the problem might be specific to a single chipset which devs do not necessarily have available. If you want any guarantee of a fix, you need to contribute time
Comment
-
Originally posted by dungeon View PostI contributed my time as a user more then enough, right now i discuss something other on bugzilla :... well not this one, i am waiting for llvm scheduler to be turned on and if performance is still lower then mesa at begining of this month i will probably bisect that .
Comment
-
Originally posted by tarceri View PostSadly we already know.
Code:Most CPU bound cases are helped and some of our internal bind_buffer_object heavy benchmarks gain up to 10%.
Last edited by dungeon; 29 January 2015, 05:42 PM.
Comment
-
Originally posted by dungeon View PostHe, he, and please stop trolling about that ... because even Kristian does that:
Code:Most CPU bound cases are helped and some of our internal bind_buffer_object heavy benchmarks gain up to 10%.
Comment
-
Originally posted by Luke_Wolf View PostWhat part of this statement his him saying he uses gallium hud and checks by eye? This sounds more like Mesa has it's own benchmarking test suite (which it should have) and the numbers were coming out to up to 10% improvement.
And about those virtual up to tha 10% we don't know much about, only we can happily assume when someone from intel said "some of our internal heavy benchmarks gain up to 10%" that besides that is publicly unknown benchmark also usually means using intel compiler, so most of the usuall distribution users won't see that gain - it is more likely around 1.5% that is what i said in first post of this thread, etc...Last edited by dungeon; 29 January 2015, 06:56 PM.
Comment
-
Wait, does Kristian imply here that futexes have too much overhead? On ARM Cortex A9 I recall the uncontended futex lock case to be around 260 cycles (vs 1600 for kernel-arbitrated mutexes). What insane amount of locks are taken that a reduction of 100 cycles max. per lock/unlock op results in a 10% speed improvement? Or was Mesa bypassing the regular futex codepaths?
Comment
Comment