00:02 tuxd3v: its now compiling for some time now(fingers crossed)
00:03 tuxd3v: probable I should have included -Dgallium-drivers=kmsro, what do you think?
00:03 airlied: nope no need
00:03 tuxd3v: many thanks for the help on this!! :)
00:04 karolherbst: ehh
00:04 tuxd3v: ok thanks
00:04 karolherbst: we should remove the standalone opencl support :p
00:04 jenatali: Standalone?
00:04 karolherbst: non ICD
00:04 tuxd3v: yeah standalone
00:04 jenatali: Oh, yeah for sure
00:04 tuxd3v: whatever that means
00:04 jenatali: That was a mistake to begin with IMO
00:04 karolherbst: that meas provides libOpenCL.so
00:04 karolherbst: *mesa
00:04 karolherbst: jenatali: yeah
00:04 karolherbst: but OpenGL did the same one :p
00:05 karolherbst: at least OpenCL fixed it...
00:05 karolherbst: for OpenGL we needed a third pary thing like libglvnd :D
00:06 tuxd3v: [1220/1220] Linking target src/gallium/targets/dri/libgallium_dri.so
00:06 karolherbst: jenatali: you also serialize the inline samplers within the program binary, no?
00:06 tuxd3v: it just finished :)
00:06 jenatali: karolherbst: Not sure what you mean?
00:06 airlied: ah I guess for fmin I need a more accurate min/max than glsl
00:06 karolherbst: jenatali: well.. CL allows you to dump the program binary
00:06 karolherbst: and from my understanding you have to dump the inline samplers as well I guess :p
00:06 jenatali: karolherbst: That's the SPIR-V for us
00:06 karolherbst: unless you recompile
00:06 karolherbst: ahhh
00:07 karolherbst: jenatali: you probably don't want to dump the spirv though
00:07 karolherbst: but more the closes you get to the backend
00:07 karolherbst: *closest
00:07 jenatali: I guess we could dump the NIR, but right now we go SPIR-V -> NIR -> DXIL at enqueue time
00:07 karolherbst: mhhh.. right
00:07 karolherbst: we have a similiar issue
00:07 karolherbst: hence we do a lot of passes when converting to nir
00:07 karolherbst: and store the serialized nir
00:07 jenatali: Yeah makes sense
00:08 jenatali: It'd probably make sense for us to switch to storing serialized nir as well
00:08 karolherbst: but that now annoys me as I have to think about storing all kind of additional results
00:08 karolherbst: like the constant buffer or the inline samplers :/
00:09 airlied: jenatali: do you ahve to do anything special for max/min to map NaN behaviour?
00:10 airlied:wonders have we specified nan behaviour for nir fmax/min
00:10 jenatali: airlied: Hm, I don't think so. The D3D spec for those is pretty tight with respect to NaNs
00:10 tuxd3v: cd ..
00:10 tuxd3v: sorry
00:13 airlied: jenatali: indeed d3d also has return other like CL
00:13 jenatali: airlied: One of the few places we *didn't* have to bend over backwards :P
00:14 airlied:isn't sure how best to select GL or CL beahviour in the backend here
00:14 airlied: mayube need to plumb down kernel vs compute difference
00:16 jenatali: airlied: Isn't the shader type already in the nir info?
00:16 jenatali: Or have you already thrown that away by that point?
00:16 airlied: oh I should stil have it, maybe a small bit of plumbing needed
01:13 airlied: okay my piglit is now pass 3764, fail 10, timeout 4, crash 2
01:13 airlied: timeouts are all sin/cos/tan
01:17 jenatali: \o/
01:18 jenatali: airlied: Does llvmpipe have a CL-conformant ffma?
01:19 airlied: we emit llvm fmuladd intrinsic
01:19 airlied: not sure what that does
01:19 jenatali: Probably not, that just sounds like mad
01:20 airlied: it's fused in some cases
01:20 airlied: https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
01:21 jenatali: Yeah, you'd have to use the fma intrinsic instead
01:21 jenatali: https://llvm.org/docs/LangRef.html#llvm-fma-intrinsic
01:21 jenatali: You could potentially get a win by using that instead of the libclc lowering for fma
01:22 jenatali: As in, it might significantly improve sin/cos/tan code size and perf
01:24 airlied: jenatali: oh indeed not setting lower_ffma32 helps
01:25 jenatali: airlied: You'll need to add a lowering pass to override the return from __clc_runtime_has_hw_fma32 to true as well
01:26 jenatali: That makes sin/cos/tan use more compact code with fmas, instead of larger mad chains
01:57 airlied: "OpenCL.std vloadn: expected operand P storage class to be UniformConstant or Generic"
01:58 airlied: a few tests in CI are seeing that, I might have to update SLT I suppose, hopefully not llvm
01:59 jenatali: airlied: That sounds like a validator problem to me
01:59 jenatali: vloadn should be able to take any address type
02:00 jenatali: https://www.khronos.org/registry/spir-v/specs/unified1/OpenCL.ExtendedInstructionSet.100.html says "p must be a pointer(global, local, private, constant, generic) to floating-point, integer."
02:00 airlied: oh maybe I need a newer spirv-tools
02:00 airlied: didn't want to have to build that myself
03:18 airlied: hmm spirv-tools didn't help, I guess I have to reproduce this locally
03:47 airlied: wierd local llvm/clang/spv 10 all work fine
03:58 airlied: doh dit it wrong
04:37 airlied: ah it was spirv-tools, now the CI results are a lot snaer
04:37 jenatali: Wow, that's a lot of extra tests
04:45 airlied: at least I've already fixed most of them in my other MR
04:59 tpalli: spam in gitlab: https://gitlab.freedesktop.org/bonbon242019
05:09 jenatali: And https://gitlab.freedesktop.org/BinBin
05:33 airlied: daniels: ^
06:11 tjaalton: airlied: fwiw, spirv-tools 2020.5 is now in sid
07:06 hakzsam: I think https://gitlab.freedesktop.org/acacia789h is spaming, daniels?
07:08 hakzsam: (or someone else with admin rights)
07:41 danvet_: mripard, I'd push your atomics core patch asap so people don't create more conflicts
07:45 mripard: danvet_: ack, I'll do it this morning
07:46 mripard: while I still have some coccinelle knowledge, iirc you wanted to do the same patch for pretty much every atomic hook, right?
08:19 daniels: tpalli, airlied, hakzsam: every issue and user page has a report spam button in the top right - please use that whenever you see anything
08:22 hakzsam: I didn't know that, will do next time, thanks
08:27 AndrewR: airlied, [710/710] skip: 73, pass: 601, fail: 28, timeout: 1, crash: 7 - for piglit's cl test on x86_32 :) (with your patch !7058)
08:27 tpalli: daniels will do
08:30 emersion: pq: since you're working on hdr: i remember the hdr patches for weston parsed the edid to extract some metadata. is this still necessary?
08:31 emersion: cc danvet_
08:38 pq: emersion, I still haven't get to the point of looking at actual code, but yes, I do expect it to be the case. A compositor could use information that the kernel has no use for.
08:39 emersion: ok
08:39 pq: emersion, in fact, there already are KMS properties that require userspace to parse the EDID to know which values for the property are valid.
08:39 emersion: (exerpt from #intel-gfx:
08:39 emersion: 13:16 <danvet_> j4ni, https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties <- might be good to add a few words to the EDID prop doc here and cc pq and emersion
08:39 emersion: 13:17 <danvet_> text says it's for vendor/model/serial, but should perhaps be clearer that it should not be used for anything else
08:40 emersion: pq: which ones?
08:40 emersion: only uses i know of are vendor/model/serial
08:40 pq: emersion, I don't remember exactly, I think the colorspace one. It's an enum, and the kernel simply cannot prune the possible values list just because of hotplug.
08:41 emersion: hm, gross
08:41 pq: the KMS propepties cannot be re-written in flight because how would userspace know
08:41 pq: and races too
08:41 pq: well, maybe not races
08:42 emersion: isn't a hotplug event enough?
08:43 pq: emersion, I dunno really
08:44 pq: danvet_, what do you mean the EDID blob should not be used for anything else?
08:45 emersion: danvet_: i'm unfamiliar with fastboot, how is it related to https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/443#note_625700 ?
08:45 pq: there is quite a lot of stuff for e.g. HDR in there, like supported color spaces, EOTFs, luminances...
08:46 danvet_: pq, we had epic lols in the past because Xorg wanted to parse the modelist itself too
08:46 pq: also RGB primary chromaticities, white point, etc. that could be used for poor-man's color management if end users are lucky enough to have it correct
08:46 danvet_: so everytime there's a new extension we had to fix parsers in both places
08:46 pq: danvet_, the kernel provides modelist, but the things I'm talking about are thing the kernel will never care about.
08:46 danvet_: yeah maybe this is different
08:47 emersion: will it really be "never ever"?
08:47 danvet_: emersion, in the end it's a balance
08:47 pq: danvet_, so yes, by all means, do document that anything the kernel already provides, userspace should not try to parse from EDID again.
08:47 emersion: e.g. could the driver decide to prune some supported color spaces because of e.g. bw?
08:47 danvet_: if chances are low enough, well let userspace have some fun too
08:47 pq: but things the kernel does not provide we do need to parse in userspace from EDID
08:48 pq: emersion, color spaces do not affect bandwidth
08:48 danvet_: emersion, it's a combo with the mode
08:48 danvet_: if you pick a slow enough mode, it should pass
08:48 emersion: i guess adding a new "list of supported XXX" as a KMS prop doesn't break old user-space that tries to parse the EDID
08:48 pq: emersion, color spaces do not affect anything the kernel or the display engine do, but they affect what the *monitor* does with the video data.
08:48 emersion: ok, colorspace was just an example
08:49 emersion: but good to know this one is fine
08:49 pq: most of the HDR stuff really is just two things: describing how the monitor behaves, and telling the monitor to interpret the data in some way (communicated via HDMI or DP infoframes)
08:51 pq: it's a nice idea that the kernel would parse and expose everything about EDID, but how do yo do that in practise for the UAPI given EDID is constantly evolving?
08:52 pq: is any UAPI you can invent any better than just passing the EDID blob to userspace?
08:53 pq: IMO what we do need is a userspace library specialised for interpreting EDID blobs.
08:53 emersion: right, that's a good question
08:53 emersion: agreed
08:53 pq: such library is not in scope in the CM&HDR efforts I'm involved with
08:53 emersion: ideally this lib could be shared with the kernel, but hrm
08:53 pq: good luck with that
08:53 emersion: :P
08:54 emersion: the kernel EDID helpers work, but aren't great
08:54 pq: why would be kernel want to carry code for parsing piece of EDID it will never use itself?
08:54 pq: *the kernel
08:54 emersion: "this value needs to be divided by $magic_number and added to $other_magic_number to be meaningful"
08:55 emersion: the kernel extracts a lot of info from EDIDs already
08:55 pq: but not all
08:56 pq: the library should also come with a massive test suite (eventually)
08:56 emersion: yeah
08:56 emersion: i've been experimenting with ideas for libedid
08:56 emersion: one way was to generate the parsing code, but IMHO EDID is not regular enough to make this worth it
08:57 pq: if code is used in kernel, then it's upstream must be the kernel tree, right?
08:57 emersion: i think so?
08:58 pq: if the library lives in the kernel tree, will people accept it if it does a lot more than what the kernel needs? And how do you arrange the test suite? How hard will it be to contribute to?
08:59 pq: by people I mean kernel maintainers
08:59 emersion: i think it would be better to start as a user-space-only lib, and see what happens from there
08:59 emersion: s/better/easier/ at least
08:59 pq: I think so too
09:00 pq: ajax started something ages ago, too, IIRC, but I forgot its name
09:01 emersion: this? https://git.linuxtv.org/edid-decode.git/
09:01 emersion: it only prints stuff, sadly
09:02 pq: no, that one seems active :-)
09:03 pq: libminitru
09:03 danvet_: tzimmermann, send-email is very hard to get through corporate firewalls
09:04 pq: emersion, https://lists.x.org/archives/xorg-devel/2010-January/004681.html
09:04 emersion: ah, interesting
09:05 tzimmermann: danvet_, idk
09:05 tzimmermann: danvet_, but we received the result
09:05 tzimmermann: it might just be a misconfiguration
09:08 pq: emersion, I agree with what ajax wrote there about "answering questions" instead of producing a structure.
09:08 pq: as the API model
09:10 emersion: that's interesting, but would be pretty opinionated
09:10 danvet_: emersion, pq oh one thing I just remembered why kernel parsing is Good (tm)
09:10 danvet_: not everything is in the edid
09:10 danvet_: we have dp aux too
09:10 emersion: … and quirks
09:10 danvet_: yup
09:10 pq: emersion, examples of things the kernel will never ever use (IMO): primary and white-point chromaticities; I doubt the kernel will ever grow color management code making use of those. Color managed fbcon?? :-P
09:10 danvet_: well, the quirks just exist for stuff the kernel has to understand
09:11 danvet_: pq, atm I'm dreaming more of an fbcon that's not so popular with syzbot exploit repots :-)
09:12 pq: danvet_, what does dp aux provide and may it override what EDID says?
09:12 danvet_: I think some bit depth stuff is in there
09:12 danvet_: tbh I'm way out of the loop on anything dp
09:12 pq: danvet_, that sounds like things the kernel provides already as UAPI anyway, or it definitely should
09:12 emersion: vsyrjala: thoughts? ^
09:13 danvet_: yeah I think best is if we go pragmatic
09:13 danvet_: when we identify a need, we can add a kernel prop for it
09:13 pq: the edid parsing library would be primarily for things the kernel has no interest in or cannot provide
09:13 danvet_: and we'll get it wrong eventually, trying our best is all we can aim for
09:13 danvet_: just want to avoid us intentionally going into a "let's parse the modelist everywhere" confusion again
09:14 pq: emersion, I think being opinionated is actually necessary, so that all display servers are opinionated the same way.
09:15 pq: danvet_, totally. In practise, if the kernel does not expose something already, userspace will parse it itself.
09:18 pq: emersion, now I remember. "colorspace" is a connector enum property. For the kernel to change the allowed values in it, it would need to destroy and re-create the connector. That might be a kernel internal limitation, but I'm also not sure if a hotplug event is enough to re-discover connector properties if the connector is not new.
09:18 pq: in userspace
09:18 emersion: i see
09:19 pq: emersion, this could be worked around by adding a read-only property for "supported colorspaces". Then hotplug event would work and no kernel internal structure would need rewriting.
09:19 emersion: right
09:20 pq: but then, that property needs to be an array of colorspace enums...
09:20 pq: or a bitmask?
09:20 danvet_: we can do read-only blobs
09:20 emersion: an array of uint64_t items doesn't sound bad
09:20 danvet_: like ... EDID :-)
09:21 pq: yeah... so if userspace can parse EDID, why bother with adding the KMS UAPI for "no" reason? :-p
09:22 pq: Does the kernel actually have *monitor* quirks? Maybe only to make fbcon show up and nothing more?
09:23 pq: oh, I remember the "non-desktop" list... it went into the kernel, but arguably you don't want fbcon on HMDs so it makes some sense
09:27 emersion: kernel has a bunch of monitor quirks for the list of modes
09:27 emersion: probably also for supported formats/depths/etc
09:58 vsyrjala: there are a bunch of annoying quirks that actually modify the edid. kinda stopping me from constifying the edid parser
10:00 emersion: hm
10:10 pq: vsyrjala, given documentation says: "Blob property which contains the current EDID read from the sink." I presume userspace gets the unmodified EDID blob, right? :-P
10:10 vsyrjala: no
10:10 pq: "read from the sink"
10:10 pq: thought so
10:11 pq: so the doc is incorrect
10:11 vsyrjala: that's what docs are for
10:12 jekstrand: :)
10:18 Akien: Since upgrading to Mesa 20.2.0, I get this warning on Intel HD 630 when running any Vulkan application:
10:18 Akien: INTEL-MESA: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0
10:19 jekstrand: You can ignore it
10:19 jekstrand: We really should only print that in debug builds and when someone tries to open perf counters.
10:19 jekstrand: dj-death: ^^
10:19 Akien: Yeah it's starting to get hits all over GitHub issues on Vulkan projects
10:22 vsyrjala: competition for the "gen7 support is incomplete" message, which everyone seems to misinterpret as "you're trying to use an unsupported vulkan feature"
10:27 tomba: Why does writeback require full modeset?
10:31 pq: tomba, on some specific driver or do you mean DRM core is forcing that?
10:31 tomba: DRM core forcing that, afaics. I'm implementing WB support for omapdrm.
10:32 pq: good question
10:37 dj-death: jekstrand: the problem is that you won't even have the extension to try to open it :/
10:37 dj-death: jekstrand: or we enable the extension always but it'll fail CTS
10:38 jekstrand: dj-death: :-/
10:40 dj-death: or sysctl dev.i915.perf_stream_paranoid=0 becomes a prerequesite to run CTS
10:40 dj-death: I don't have an easy solution
10:40 jekstrand: Yeah, neither do I. I also don't want people whacking security options just because a warning scares them
10:50 pcercuei: another problem with drm_display_mode... The .clock field should be the rate at which *pixels* are emitted, or the actual clock frequency set to the hardware?
10:51 vsyrjala: it's the dotclock
10:51 pcercuei: Trying to support MEDIA_BUS_FMT_RGB888_3X8. So each clock tick is for one sub-pixel
10:52 vsyrjala: i guess you want mode.clock*3 for your internal clock then
10:53 pq: pcercuei, DRM docs say: "Pixel clock in kHz"
10:54 pcercuei: I find that a bit ambiguous
10:54 pcercuei: since my pixel clock is driving sub-pixels
10:55 pcercuei: But thanks for the clarification!
10:55 vsyrjala: isn't that a sub-pixel clock then?
10:55 pcercuei: I guess it is
10:56 pq: I might have trouble interpreting pixel clock with chroma-sub-sampled pixel formats :-)
10:58 pq: OTOH, pixel clock is just a scaling factor for converting timings from unitless integers to seconds I suppose.
10:59 pq: video mode timings
10:59 vsyrjala: the place where it tends to get muddy is when there's an internal bus that is clocked higher than the actual display timings the user will see
10:59 vsyrjala: eg. dsi command mode
11:00 vsyrjala: but at least for all user visible modes the clock should match what the user will see
13:09 Venemo: daniels: I've got another CI failure with MR 6964, it says "script failure"
13:12 daniels: Venemo: did you look at the log? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4935140#L4330
13:12 daniels: the compile failed
13:12 daniels: softpipe also failed a GS test https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4935177#L441
13:12 Venemo: I did look at the log, there are a bunch of warnings in util
13:13 daniels: search for 'error:' or just click on the link where it goes to the line where there's a new error introduced
13:13 daniels: ../src/compiler/nir/nir_gs_count_vertices.c:65:24: error: use of GNU empty initializer extension [-Werror,-Wgnu-empty-initializer]
13:13 daniels: bool cnt_found[4] = {};
13:13 Venemo: ehhh
13:14 Venemo: why did this not get caught by the previous CI runs?
13:14 Venemo: I'll fix that
13:14 MrCooper: probably because those were still using clang 9, now we have 10
13:15 daniels: because it was introduced in your MR ... ? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6964/diffs#0ae86069c7fe198c8ad58c085df8cda9439f5964_57_65
13:15 Venemo: my MR has 47 CI pipelines
13:15 Venemo: none of those complained
13:15 MrCooper: daniels: where's the "link where it goes to the line where there's a new error introduced"?
13:16 Venemo: I'll take a look at the softpipe test, too
13:16 MrCooper: daniels: nvm, you were just referring to your link above
13:17 MrCooper: Firefox doesn't actually jump to that line when loading though :(
13:17 Venemo: how can you tell which softpipe test failed?
13:18 mripard: danvet_: if you have some time, I'd like your input on https://lore.kernel.org/dri-devel/20201008112519.43691-3-maxime@cerno.tech/T/#u
13:18 mripard: I'm not sure it's sane
13:18 MrCooper: Venemo: looking at daniels' URL above, check line 441 in the job log
13:19 daniels: which appears to be a flake based on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7070 so it should be skipped ...
13:19 MrCooper: Venemo: rebasing on current master should skip that one
13:19 Venemo: so, I didn't break it?
13:20 MrCooper: no, you get to complain again how CI is a conspiracy against you ;)
13:21 Venemo: awesome
13:28 vsyrjala: mripard: looks unsafe. that other crtc state can go poof at any time
13:52 ishitatsuyuki: I'm facing fence timeout running a compute workload with AMDGPU on Navi 10. Is there any debug option I can enable to dig into this?
13:53 hakzsam: VK or GL?
13:54 ishitatsuyuki: VK
13:55 hakzsam: are you using RADV?
13:55 ishitatsuyuki: Reproduced with both RADV and AMDVLK
13:55 hakzsam: what mesa version?
13:55 ishitatsuyuki: 20.2.0
13:55 mripard: vsyrjala: yeah, that's one of the things I was afraid of
13:56 mripard: vsyrjala: I'm not entirely sure how to do better though
13:56 hakzsam: ishitatsuyuki: did you try RADV_DEBUG=llvm ?
13:56 ishitatsuyuki: not yet, I can try it but I feel it won't help
13:56 ishitatsuyuki: recovery doesn't work btw so I need a hard reset to get back, so good luck to me testing it
13:57 hakzsam: do you have a test case so I could try on my side?
13:58 Venemo: thx daniels & MrCooper it's fixed and merged now
13:58 vsyrjala: mripard: drivers/gpu/drm/i915/display/intel_global_state.c is what i did for cross-crtc things in i915. it's like drm_private_obj, except doesn't always serialize everything due to an ad-hoc rw locking scheme rather than the single mutex
13:59 ishitatsuyuki: hakzsam: I just tried RADV_DEBUG, no luck. The application is Apache TVM but it's a bit annoying to setup
14:00 hakzsam: ishitatsuyuki: can you try "RADV_TRACE_FILE=$HOME/radv_trace your_app &> radv_hang_report" and upload the files somewhere?
14:00 hakzsam: feel free to fill an issue here too https://gitlab.freedesktop.org/mesa/mesa/-/issues
14:01 mripard: vsyrjala: I'll have a look, thanks!
14:13 danvet_: mripard, uh that doesn't work
14:13 danvet_: you can't access obj->state pointers in commit
14:13 danvet_: since you neither have the ordering nor the lock
14:13 danvet_: so the usual way to do this is to compare whether any of the $derived_state input variables has changed
14:13 danvet_: if no -> do nothing
14:14 danvet_: if yes -> acquire the global $derived_state and recompute everything
14:14 danvet_: in atomic_check
14:14 danvet_: if you want to avoid needless synchronization with other crtc
14:14 danvet_: have a copy of the input state of each crtc in $derived_state
14:16 danvet_: mripard, maybe we should have an example doc somewhere that shows how this is done
14:16 ishitatsuyuki: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3618 cc hakzsam
14:25 mripard: danvet_: we don't really have a dependency on any input variable here, it's more of a global state that needs to be shared across all CRTCs
14:26 mripard: but from what you're saying, I guess you'd prefer to store the free channels in the global state, and then only update the muxing if a CRTC was either disabled or enabled in the state being checked / committed?
14:27 danvet_: mripard, I think yes
14:27 danvet_: let me try to explain in full abstract nonsense
14:27 danvet_: so we have a few things
14:28 danvet_: there is a $global_state that controls some kind of shared resource
14:28 danvet_: $global_state for you is this hw mux, but it could be fifo assignment between crtc, or really anything
14:28 danvet_: so somewhere you have a spec that tells you how to program that $global_state
14:28 danvet_: in abstract nonsense
14:29 danvet_: $global_state = f( $input_state)
14:29 danvet_: now the input state is probably part of a bunch of drm_foo_state structures (crtc in your case)
14:29 danvet_: so the usual approach I recommend here is
14:30 danvet_: a) for every drm_foo_state that contains a part of $input_state, check whether that input_state has changed: if no, done, if yes, set needs_global_state_recomputation
14:30 danvet_: do a) as a loop over all foo states
14:30 danvet_: if needs_global_state_recomputation is set, grab that state, but _not_ all the other drm_foo_states that comprise the overall $input_state
14:31 danvet_: (that was b))
14:31 danvet_: c) for the states you do have in your drm_atomic_commit, copy $input_state from drm_foo_state to drm_$global_state_state
14:31 danvet_: this way you have the entire $input_state in drm_$global_state_state
14:32 danvet_: and you don't have to peak in a dangerous way, or in a way that forces synchronization we don't want (crtc should be independent by default)
14:32 danvet_: d) compute new global state with f()
14:32 danvet_: e) commit this entire pile
14:32 danvet_: e) is a bit tricky, since you need to order stuff correctly :-)
14:33 danvet_: so probably want the usual drm_crtc_commit pointer and tracking on your global state
14:33 danvet_: or something like that
14:33 danvet_: the shitty approach is that every time you notice a need to recompute the global state
14:33 danvet_: you simply grab all locks, grab all states, and do it
14:34 danvet_: but that causes stalls that shouldn't be there
14:34 danvet_: (i915 is unfortunately shitty right now on gen12 afaik)
14:34 danvet_: also note that with the EBUSY patch I just merged, such shitty drivers will get greeted with a splat :-)
14:34 danvet_: because it's really not what compositors want to happen
14:35 vsyrjala: it's going to happen whenever you need to properly sequence the hw state updates
14:43 danvet_: vsyrjala, yeah, but I'm hoping that most hw just put that stuff accidentally in the same register or something
14:43 danvet_: and not that you actually have to stop the other crtc for a bit while you change it
14:44 danvet_: so you might need to wait for a commit on a different crtc that also touched global_state
14:44 danvet_: but for steady-state flips that really shouldn't happen
14:44 danvet_: whereas if you go with the "grab all the states" you force a dropped update even in the steady state
14:44 danvet_: which is kinda bad
14:45 danvet_: pinchartl, where was v4l1?
14:45 danvet_: I'm trying to find out when userptr was first added to v4l
14:45 danvet_: atm I can only find v4l2 in 2002
14:48 pinchartl: danvet_: v4l1 is oooooold
14:48 pinchartl: introduced in 1999
14:48 pinchartl: V4L2 was added in 2002
14:48 pinchartl: and V4L1 (just called V4L) deprecated in 2006
14:50 mripard: danvet_: I'll think about what you said some more and will try to implement something, thanks
14:53 vsyrjala: danvet_: we have to guarantee some kind of global order for the commits. otherwise your old state can end up being different during compute and commit phases
14:53 danvet_: pinchartl, well I'm trying to find it
14:53 danvet_: and failing
15:13 pinchartl: danvet_: find what ? the API ? or when i was added ?
15:14 pinchartl: danvet_: removal in 88ae7624a6fe
15:20 danvet_: pinchartl, hm no userptr in v4l1?
15:20 danvet_: or am I blind?
15:22 pinchartl: I don't remember how that API worked :-)
15:23 pinchartl: but why do you care about V4L1 ? it's dead
15:46 vsyrjala: wasn't there just a "here's a physical address go dma stuff into it" in v4l1? or was that just a hack i remember doing back in the day to get my capture card writing directly into my graphics card's memory?
15:50 pinchartl: vsyrjala: there was that, to capture directly into the graphics card framebuffer
15:51 pinchartl: that's VIDIOCSFBUF
16:26 danvet_: tzimmermann, christian könig needs a backmerge of drm-next into drm-misc-next to get at 0552daac2d18f for his cleanup series
16:26 danvet_: [PATCH 6/6] drm/prime: document that use the page array is deprecated v2
16:27 tuxd3v: hello all,
16:28 tuxd3v: mesa Clover is reporting 0 devices :(
16:28 tuxd3v: https://paste.debian.net/1166508/
16:28 tuxd3v: I built it yesterday with your support with:
16:28 tuxd3v: /opt/meson-0.55.3/meson.py build/ --buildtype release --prefix=/opt/build --libdir=lib/x86_64-linux-gnu -Dgallium-drivers=radeonsi,swrast -Dgallium-opencl=icd -Dplatforms=x11 -Dvulkan-drivers= -Ddri-drivers= -Dllvm=true
16:29 tuxd3v: I updaled my dynamic linker
16:30 tuxd3v: and created '/etc/OpenCL/vendors/mesa.icd'
16:30 tuxd3v: clinfo detects it as a platform( Clover ), but no devices
16:31 tuxd3v: can any one help me
16:31 tuxd3v: thanks a lot
16:48 pmoreau: tuxd3v: Could you please run clinfo inside a debugger and put a breakpoint in core/platform.cpp on line 33?
16:50 tuxd3v: pmoreau, I already worked with the debugger but was long time ago :(
16:50 tuxd3v: any hints?
16:51 pmoreau: If you have gdb, you can do `gdb clinfo`, and then `b core/platform.cpp:33` followed by `r`.
16:52 tuxd3v: Make breakpoint pending on future shared library load? (y or [n])
16:52 pmoreau: y
16:52 tuxd3v: I assume yes
16:52 tuxd3v: oki :)
16:52 pmoreau: Indeed :-)
16:53 pmoreau: Once it hit the breakpoint, could you please run `p n` to see how many devices are reported?
16:53 tuxd3v: after hitting 'r'
16:54 pmoreau: Right, `r` is a shortcut for the `run` command
16:54 tuxd3v: https://paste.debian.net/1166510/
16:55 tuxd3v: now I will run the 'p n' :)
16:55 pmoreau: It won’t work as the program already exited.
16:56 pmoreau: Mmh, why did it not stop at the breakpoint.
16:56 tuxd3v: No symbol "n" in current context.
16:56 tuxd3v: yeah
16:56 tuxd3v: I will repeat all
16:57 tuxd3v: it dies before achieving the beakpoint I believe?
16:58 pmoreau: It does not die, it just exists normally as it reached the end.
17:00 tuxd3v: No symbol table is loaded. Use the "file" command.
17:00 tuxd3v: Make breakpoint pending on future shared library load? (y or [n])
17:00 tuxd3v: when I do 'b core/platform.cpp:33'
17:01 pmoreau: I think the breakpoint does not work because you do not have any debugging symbols.
17:01 tuxd3v: should I compile it with '--buildtype debug'?
17:02 tuxd3v: I compiled it with 'release' yeah
17:02 tuxd3v: does you now how to reset the build config for mesa with meson?
17:02 pmoreau: That would definitely make it easier to debug. :-) debugoptimized might work as well, but could get in the way.
17:03 pmoreau: In your build folder, you should be able to run `meson configure -Dbuildtype=debug`
17:10 pmoreau: tuxd3v: I’ll need to step out for a bit. Check that that `n` variable is different from 0, put a second breakpoint in core/device.cpp on line 54 and run `continue`, check that you hit it, and if yes go through that function call by using the `next` command (or its shortcut `n`) to figure out where it is failing.
17:11 tuxd3v: pmoreau, thanks a lot for the help! :)
17:11 tuxd3v: ok
17:11 tuxd3v: I will try :)
17:24 tuxd3v: woow, just compiling it with 'debug' and its working :/
17:26 tuxd3v: https://paste.debian.net/1166514/
17:28 Lyude: mripard, tzimmermann, j4ni, vivijim, going to merge this https://patchwork.freedesktop.org/series/82504/ through drm-intel-next-queued, is that OK with yall?
19:41 airlied: MrCooper, anholt : I noticed rebuilding x86_test-gl we clone VK-GL-CTX then do a git fetch origin master got backport one surfacless commit
19:41 airlied: that git fetch origin master takes for ever
19:42 airlied: maybe just don't clone with depth 1 or try and git fetch something more specific, or just carry the backported patch locally
19:43 anholt: airlied: I do agree that -depth 1 on a specific branch is the way to go
19:44 anholt: -depth 1 + fetch should be basically the same time as ! -depth 1
19:44 anholt:has another CI branch MR that cherry-picks a bunch more fixes, I could update to do that if we can figure out why the deqp runner is choking. :(
19:48 airlied: anholt: I think it takes longer to do the clone + fetch because it ends up doing a lot of have I got this already operations
19:48 airlied: it's been sitting here for >5 minutes now
19:48 anholt: oof. that's worse than I would have thought
19:52 airlied: bleh 10 mins I'm gonna fix this
19:54 airlied: anholt: 7073 has a just clone without depth fix in it
20:00 daniels: git protocol v2 is really really bad for ref negotiation when you have a ton of them on the remote
20:00 airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7073/diffs?commit_id=b005909263715b4c6d289451014b8f405b3d5a97
20:00 airlied: anholt, daniels : ack for that? so I can land my mr once it builds?
20:01 daniels: airlied: A-b
20:01 anholt: ack
20:04 airlied: bleh actualy cloning also is taking quite a while, wtf is in that repo
20:05 daniels: I wonder if it's a distant fork of LLVM
20:05 airlied: but still a lot faster
20:06 airlied: 284MB Repo
20:06 airlied: resolving deltas seems to get stuck at 4%
20:06 airlied: and a couple of other spots
20:07 daniels: oh sorry, it's CTS not Translator, definitely not a distant LLVM fork
20:08 airlied: yeah resolving delats 39% locally takes quite a while
20:13 airlied: playing locally clone depth 1 + fetch depth 1 is a lot faster, but cherry-pick fails
20:14 anholt: what I did in the past was just throw a branch up with the tree I wanted, and fetch --depth 1 that
20:14 anholt: I don't know why robclark didn't go that route this time.
23:53 vivijim: Lyude: ack