19:57 anarsoul: could anyone explain life time of pipe_surface for me? Are there any guarantees that it doesn't exceed life time of corresponding pipe_context?
19:59 imirkin_: it's not supposed to.
19:59 imirkin_: but sometimes it does :)
19:59 imirkin_: iirc svga is sensitive to this
19:59 anarsoul: I just got it in lima and it's confusing since lima doesn't expect that
20:00 imirkin_: there might be a PIPE_CAP for it
20:00 imirkin_: that enforces it
20:00 imirkin_: at some cost in the st
20:01 imirkin_: i can't find it, so probably not...
20:01 anarsoul: well, anyway I need to rework plbu cache so might as well refactor lima_surface_destroy()
20:55 robclark: anarsoul: pipe_surface is usually/often transient (ie. it could be recreated for a given pipe_resource).. so generally not the best place to cache things
20:56 anarsoul: robclark: things are cached for pipe_context
20:56 anarsoul: but we store pointer to context in lima_surface
20:57 anarsoul: and it appears that this pointer may become invalid while lima_surface is still alive
20:57 robclark: ok, I've not looked into what you are doing.. but just figured I should point that out (for fd_batch cache I use the underlying pipe_resource rather than the pipe_surface from the pipe_framebuffer_state, for this reason)
20:58 anarsoul: thanks :)
20:58 robclark: np
21:19 robclark: imirkin_: is pipe_blend_state::logicop_enable something that is not expected to apply to integer formats? I'm wanting to move blend state (for a6xx) into a stateobj.. and after switching on PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND that is the one remaining thing that doesn't let me pre-bake the state and not fix things up at emit time.. one option might be adding a new cap, and moving logicop_enable flag to
21:19 robclark: pipe_rt_blend_state.. not sure if per-mrt logicop_enable is a thing that would make sense for any other reason..
21:28 Kayden: logic operations are supposed to apply to integer surfaces
21:28 Kayden: see the last issue of https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_integer.txt
21:30 robclark: hmm
21:32 robclark: we intentionally disable them for integer formats.. which might be a gl vs gles limitation of the hw.. I'm assuming imirkin_ was the one who decided we need to do that on *some* gen of adreno (and then it got copy-propagated into newer gens)
21:33 robclark: looks like to disable blending of integer formats..
21:35 Kayden: i965 seems to only enable them on UNORM formats, due to hardware limitations...GL requires them to work, but...they don't, so...whatcha gonna do
21:35 Kayden: looks like modern intel is OK but SNB for example is not
21:36 robclark: I suspect it is about logic ops that require reading dest
21:36 Kayden: you can't have logicops and blending at the same time
21:37 robclark: I guess the question is whether we can do logic-ops that require reading dst..
21:38 robclark: any idea how much of this is gl vs gles? I guess we have reasonable coverage of gles in CI so I can just push experiments and see what breaks.. but not sure offhand if there are gl sharp edges that we don't have with gles CI..
21:38 Kayden: ES 1.1 contains logic ops that read dest
21:39 robclark: but not integer formats.. and I guess we don't have gles1 coverage in CI..
21:39 Kayden: gles2 removes them it seems
21:39 robclark: (but I assume by now everyone just pretends gles1 doesn't exist)
21:42 robclark: I suppose the easy thing to do might be remove the special handling for int formats and worry about it if anyone notices something that cares.. because less CP_BUSY_GFX_IDLE is a good thing for fps..
21:47 imirkin_: tbh, not sure why logicop would be explicitly disabled for integer formats
21:47 imirkin_: probably because i thought that sounded reasonable at the time, and there were no tests for it, so ...
21:49 robclark: looks like it dates back to f866446e8c4c77cfe0f1f78929ff22ba1d4ae4aa .. although possibly logicop was an innocent bystander..
21:50 robclark: (otoh, not that I'd expect myself to always remember the reason for a 6yr old commit)
21:50 Kayden: in i965, f6e82cd2a18b0edebe3e4102fc93b552e708935a notes that sandybridge hit GPU hangs with logic ops on integer textures - but doesn't say what program hit that. I don't see any piglit tests.
21:51 Kayden: would be somewhat surprised if recent adreno didn't support this, though
21:52 robclark: heh, I guess you have me beat by a couple years in the git archaeology dept..
21:52 robclark: I guess if it is a thing in modern dx, there is a reasonable chance adreno supports it
21:54 robclark:kinda wishes the gitlab "blocked" pipeline thing for non-MR pipelines didn't require waiting for build to finish to click "run" on the test jobs
21:57 anarsoul: gitlab is down?
21:57 Kayden: it'll probably be up in ~1 minute
21:57 Kayden: yep already back
21:57 Kayden: it's usually down for the precise amount of time that it takes people to type "is gitlab down?" on IRC
21:59 robclark: damn, now I need to re-click meson-arm64 build
21:59 robclark: (and wait to click more things)
22:00 Kayden: :(
23:15 imirkin: Kayden: fwiw there's a QCOM_logic_op or something like that
23:15 imirkin: for ES2
23:17 imirkin: which seems to have been deleted from history, but there are definitely references to it that google can find. (AMD_logic_op)
23:17 imirkin: and AMD_alpha_test
23:18 robclark: what are the odds that qcom s/AMD/QCOM/g for the set of a2xx extensions?
23:18 imirkin: they kept it as AMD, i believe
23:18 imirkin: but those exts were precisely for a2xx
23:18 imirkin: not for desktop amd hw
23:18 robclark: a2xx was a weird on.. it was more early-desktop-gl-called-mobile..
23:19 robclark: (ie. lack of fp16, and other desktop gl features)
23:19 imirkin: for desktop that stuff already existed, anyways
23:19 robclark: right