08:50 <rellla> cwabbott: is there any where an example in the nir_lower/opt_* code which inserts a mov op that depends on the parent instruction?

08:52 <rellla> (('fddx', ('fabs', a)), ('fddx', ('fmov', ('fabs', a))))

08:52 <rellla> in pseudocode :)

08:52 <rellla> *opt_algebraic pseudocode

09:01 <cwabbott> rellla: first off, opt_algebraic doesn't even work after modifiers are introduced (it isn't meant to be run that late)

09:02 <cwabbott> you'll need to do it yourself, or do it in ppir

09:08 <rellla> cwabbott: i'll think i'll do it in ppir, because it's lima specific anyway...

09:11 <enunes> rellla: don't we always lower abs to a mov already, you need another one?

09:29 <rellla> enunes: yes, ppir_op_abs gets ppir_op_mov, but it seems, that we need an extra mov if fddx has fabs as parent instruction. if suspect, it's only necessary if fabs is combined with a negation, but the blob seems to do the following all the time:

09:29 <rellla> fddy(fabs) -> fddy(fmov(fabs))

09:30 <rellla> thats probably, why glsl-derivs-abs-sign fails http://imkreisrum.de/piglit/glsl-derivs3/

09:35 <enunes> so that results in fddy(mov(mov)) ?

09:37 <rellla> enunes: this is what the blob produces for glsl-derivs-abs-sign: https://pastebin.com/raw/ugJw9Cbr (from cwabbott)

09:37 <rellla> https://freenode.irclog.whitequark.org/lima/2019-07-17#24985043;

09:38 <cwabbott> enunes: no, it's just that the blob doesn't support abs/neg modifiers on the ddx/ddy instructions, so we have to undo the nir modifier pass

09:39 <cwabbott> apparently you can get it do neg and abs by being a little clever, but both together doesn't work

09:40 <cwabbott> it's a little tricky since the HW op actually has two sources, presumably it works like an add where one of the sources is swapped with another pixel in the quad

09:50 <enunes> I see, so this is for when the nir src already comes with .negate set, not for when we have a separate fneg/fabs node

11:33 <rellla> hm, what happens, if both, negate and absolute modifiers, are set?

14:04 <rellla> enunes: regarding the force zswrite option, see https://freenode.irclog.whitequark.org/lima/2019-07-16#24981596;

14:06 <rellla> i don't really understand the cases, where it needs to be enabled automatically... i just followed anarsoul's suggestion

14:07 <anarsoul> rellla: it has to be enabled for all cases but for scanout

14:08 <rellla> anarsoul, so it does what we want already?!

14:09 <anarsoul> I think so

14:09 <anarsoul> I doubt any other app tries to read out depth/stencil buffer via glReadPixels()

14:11 <enunes> is it possible to enable it automatically when we have glReadPixels?

14:11 <enunes> or glReadPixels reading those buffers

14:14 <enunes> yeah probably not if that needs to go on the frame reg

14:17 <enunes> I guess I would vote to remove the optimization if the buffer was allocated with depth/stencil, otherwise we rely on a debug option to do things that should be valid on opengl es

14:17 <enunes> or have the debug option to do the optimization

14:26 <anarsoul> enunes: I believe glReadPixels does it *after* drawing is done

14:26 <anarsoul> enunes: and removing this optimization isn't a good idea since it'll hurt performance badly

14:27 <anarsoul> basically you need 2x of memory bandwidth if you always write out depth/stencil buffer

14:27 <anarsoul> hi yuq825

14:27 <anarsoul> enunes: IIRC I tried it and it was 25-30% FPS drop in glmark

14:29 <cwabbott> anarsoul: you can't use that optimization unless the app tells you to via glInvalidateFramebuffer(), the driver has no idea if the app will use the depth buffer in the future

14:29 <cwabbott> if the app doesn't perform as well, well then that's the app's fault, and the blob won't do any better

14:29 <anarsoul> cwabbott: blob does this optimization

14:32 <cwabbott> anarsoul: for glmark2, how does the blob know that the depth buffer is invalidated?

14:33 <anarsoul> cwabbott: I believe it just never allocates depth buffer for scanout

14:33 <cwabbott> ok, so then it sounds like you're missing some optimization

14:35 <cwabbott> it's better to be correct by default first, and then later add per-app workarounds or optimizations, then adding a flag for piglit to enable the correct thing

14:36 <rellla> personally i think we don't need this to be merged, it only showed me, that the gl_FragCoord implementation was right...

14:44 <anarsoul> rellla: well, we still need it to confirm that gl_FragCoord isn't broken :)

14:44 <rellla> anarsoul: well, that the confirmation: http://imkreisrum.de/piglit/glsl-fs-fragcoord4/ :)

14:45 <rellla> if i remove the debug option, the latter 2 fail.

14:50 <anarsoul> rellla: well, it's not one time thing

14:50 <anarsoul> what if it breaks in future?

14:55 <bshah> hm, depth/stencil buffer topic in messages here triggered by curiosity... so remember I talked about simple Qt/QML app not rendering? one of the bit I can see is qt complains about missing depth/stencil buffer, however AFAIU, it is implemented in mesa already.. : https://gitlab.freedesktop.org/mesa/mesa/commit/fef2f10cc2ad298f179d5a5aa0a210fbea02d95f (19.1.0 release is what I am using)

14:56 <bshah> am I missing something basic here? or?

14:57 <bshah> https://invent.kde.org/snippets/330#L28 context log ^^

15:00 <enunes> anarsoul: do you mean that the blob doesnt allocate the depth buffer in glmark2, or the application? if the application doesnt allocate it, then it makes sense to not do the writeback right? this is what we already have?

15:00 <enunes> other than that I agree with cwabbott , what we can also possibly do is have the env var to enable the optimization and maybe spit out a ppir_debug suggesting its use to improve performance in some applications, if it makes that much big difference

15:01 <enunes> bshah: yes it should already be supported, the discussion is about an optimization that breaks glReadPixels from the depth buffer, not sure if Qt does that

15:01 <enunes> bshah: 19.1 misses many features, I would really recommend to do your testing with master

15:02 <anarsoul> enunes: it doesn't allocate depth buffer for scanout since it makes no sense if application doesn't read it back

15:02 <anarsoul> enunes: mali4x0 uses tile buffer for depth

15:02 <bshah> enunes: hm, now I wonder why qt think it is not supported.. hmm

15:03 <bshah> I'll read qt code I guess :)

15:03 <enunes> well it can't know if the application will want to read it or not

16:16 <bshah> question, if I want to grab apitrace for debugging application with lima, should I use any special args?

16:16 <bshah> or simply apitrace trace --api egl would do?

18:41 <anarsoul> enunes: what would you read it for? :)