ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel has landed in mainline, userspace driver is part of mesa - Logs at and - Contact ARM for binary driver support!
kaspter has quit [Ping timeout: 276 seconds]
kaspter has joined #lima
kaspter has quit [Ping timeout: 245 seconds]
kaspter has joined #lima
egbert has quit [Ping timeout: 260 seconds]
egbert has joined #lima
mripard has quit [Ping timeout: 264 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
maciejjo has quit [Remote host closed the connection]
_whitelogger has joined #lima
dev1990 has quit [Quit: Konversation terminated!]
linkmauve has left #lima ["Disconnected: closed"]
smaeul has quit [*.net *.split]
bshah has quit [*.net *.split]
mmind00 has quit [*.net *.split]
smaeul has joined #lima
bshah has joined #lima
linkmauve has joined #lima
kaspter has quit [Quit: kaspter]
kaspter has joined #lima
kaspter has quit [Ping timeout: 264 seconds]
kaspter has joined #lima
<linkmauve> I printed the st->shader_has_one_variant decision process for each shader being compiled, they all gave the same results:
<linkmauve> vs: shader_has_one_variant=n, has_shareable_shaders=n, clamp_frag_depth_in_shader=n, clamp_vert_color_in_shader=n, lower_point_size=n, lower_ucp=y
<linkmauve> fs: shader_has_one_variant=n, has_shareable_shaders=n, lower_flatshade=y, lower_alpha_test=y, clamp_frag_color_in_shader=n, clamp_frag_depth_in_shader=n, force_persample_in_shader=n, lower_two_sided_color=y, lower_texcoord_replace=n
<anarsoul|2> linkmauve: it could be missing support for shareable shaders
<anarsoul|2> I can look into what needs to be done to enable it later this week
<linkmauve> Thanks. :)
<anarsoul|2> meanwhile you can try this:
<anarsoul|2> but I expect it to fail miserably :)
<linkmauve> Let’s try!
<linkmauve> It didn’t fail in any way (GTK is single-threaded, that might be why?) but wasn’t any faster.
<linkmauve> (17.18s this time.)
<anarsoul|2> :(
<anarsoul|2> btw, is it compilation time?
<anarsoul|2> can you capture the shader for me please?
<linkmauve> It’s probably still reproducible with blend.glsl.
<linkmauve> Do you want the full shader-db output?
<linkmauve> Err, input.
<anarsoul|2> I want a shader captured with MESA_SHADER_DUMP_PATH
<linkmauve> anarsoul|2, contains all shaders.
<anarsoul|2> please capture shaders with MESA_SHADER_CAPTURE_PATH, I want something that I can feed into compiler without much effort
<anarsoul|2> so yeah, I want *.shader_test for mesa-shader-db
<linkmauve> Same URL.
<linkmauve> (I was intrigued why you wanted a MESA_SHADER_DUMP_PATH instead of MESA_SHADER_CAPTURE_PATH but didn’t question it. ^^')
<anarsoul|2> I keep forgetting which one generates shader_test
<anarsoul|2> which one takes 17s to compile?
<anarsoul|2> oh, so it's not a single shader that takes 17s? but all of them?
<anarsoul|2> well, that's 96 shaders (49 vs, 49 fs) after all...
<linkmauve> Yes, including some huge ones with like 21 spills.
<linkmauve> But before 1d5ce66b02016a8c985e3e3cc44df65ccfacca48 it took only ~7s to build everything.
<linkmauve> Still very long (not using the GLES backend drops the total startup time to 1.5s) but already much more bearable.
<anarsoul|2> because it built it once
<linkmauve> Yes.
<anarsoul|2> meh, I'll just implement disk cache to paper it over
<linkmauve> ^^'
<linkmauve> Every compilation which does occur would still take twice as much time as before.
<anarsoul|2> OK, I asked anholt on #dri-devel about this commit
<anarsoul|2> I doubt he'll respond earlier than Monday though
<anarsoul|2> it's his daytime job :)
<anarsoul|2> anyway, I'll work on disk cache for lima, that should help with startup times, we'll figure out how to avoid compiling it second time in parallel
<linkmauve> Thanks!
<linkmauve> Oh, GTK people did a whole bunch of optimisations since then, time to rebuild.