00:00anholt: and then, of course, what you really want is some sort of microcontroller that eats a short description of the jobs to dispatch to and does those jobs in sequence without bothering the main cpu and oh hey that's the VPU for rpis except that the vpu is still running a closed blob.
00:02airlied: anholt: so on queue submit those the main thread unspool the cmd buffer to the kernel, or is it done in a second thread?
00:02anholt: airlied: haven't traced through what v3dv's doing there.
00:02anholt: main thread in the v3d case.
00:04apinheiro: > anholt: would you be fast just executing memcpys instead of using the gpu :-P
00:04apinheiro: airlied, we also evaluated this
00:04apinheiro: the issue is when deciding to use this "memcpy codepath" or the gpu codepath that we have
00:04apinheiro: on this specific case
00:04bnieuwenhuizen: FWIW wrt the cmdbuffer chaining, some apps actually do submit ~100 cmdbuffers at once with the simulataneous use bit
00:04apinheiro: with ~15k copies, that are really small
00:04bnieuwenhuizen: (e.g. dota2)
00:04apinheiro: it is really likely that a memcpy (so a cpu copy)
00:04apinheiro: woudl be better
00:05apinheiro: bnieuwenhuizen, well, but I think that dota2 is somewhat out of range for the rpi4
00:05anholt: the tiny slow memory's gonna kill you for dota
00:06bnieuwenhuizen: I dunno, pretty easy title to run, can probably get 100 FPS on a random APU
00:06airlied: just need an arm port :-P
00:07anholt: bnieuwenhuizen: well, rpi4's got 1/4 the memory bandwidth of a qcm soc I have handy, for example.
00:07anholt: but they did give it the ability to scan out dual 4k monitors, if you can ever get around to rendering that much :)
00:07airlied: apinheiro: it sounds like for smaller copues a memcpy might be less overhead than calling all the kernel ioctls
00:07anholt: airlied: that means total synchronization, though, right?
00:08apinheiro: airlied, yes exactly,
00:08apinheiro: for this case of 15k small copies, it is really likely that just a memcpy would work
00:08apinheiro: but again, the tricky part would be to decide when to use one or the other
00:08airlied: anholt: yesh it would require syncing I suppose
00:09apinheiro: specially because in this case we have 15 copies as 15k calls to vkCmdCopyBuffer with regionCount=1, so we would need to do the batching
00:34robclark: airlied: don't really need an arm port.. https://imgur.com/a/5gt22hO <-- that is snapdragon arm laptop with crazy things that HdkR does
00:48Lightkey: "crazy things that HdkR does" is a bit redundant. Though that is hardly impressive, ptitSeb got FTL: Faster Than Light running on the Pandora with his box86 emulator and that thing predates smartphones: http://repo.openpandora.org/?page=detail&app=ftl_ptitseb
00:52robclark: Lightkey: it is freedreno compiled for x86 doing ioctl calls into aarch64 kernel fwiw, so no gl translation involved
01:00pcercuei: Trying to use wlroots + cage, with not much success
01:00pcercuei: I do:
01:00anholt: on a related note, looks like I never landed that SSE code from someone doing hw accelerated diablo 2 emulation on the rpi.
01:00pcercuei: XDG_RUNTIME_DIR=/tmp/foo WLR_DRM_DEVICES=/dev/dri/card1 cage glmark2-es2-wayland
01:01pcercuei: on the ingenic-drm driver
01:01pcercuei: It doesn't throw DRM-related errors, but it throw me a EGL-related error ("Error: eglChooseConfig() didn't return any configs")
01:02pcercuei: Not sure what I'm doing wrong
01:02pcercuei: glmark2-es2-drm works fine, so it's not that
01:08pcercuei: ok, I think I need to recompile Mesa.
01:15pcercuei: ok, it works now :)
01:44jekstrand: jenatali: On the list of things that need to happen at some point: Moving the microsoft/clc_helper stuff to common code somewhere.
01:45jekstrand: jenatali: I need it for "stuff" :)
01:45jenatali: jekstrand: Yeah, I know, I've got a TODO on my backlog for it but haven't had time to get to it yet
01:45HdkR: Lightkey: Yes, box86 is a very similar project, just for 32bit x86 applications
01:46jenatali: jekstrand: Which stuff do you need? The clang invocation? SPIR-V linking? SPIR-V metadata parsing?
01:53jekstrand: jenatali: OpenCL C -> SPIR-V
01:54jenatali: You could steal it from Clover too, but I'd like to merge with that too
01:59jekstrand: jenatali: Short version is that I'm building a little OpenCL C compiler for Intel to build BVH kernels at compile time.
01:59jenatali: Oh that makes a lot of sense
01:59jekstrand: jenatali: So it's most of the same stuff as in clc_helpers.cpp
02:01jenatali: jekstrand: Were you thinking all the way to NIR as a common library then?
02:01jenatali: I guess probably not, since the NIR options would be unique
02:06jekstrand: jenatali: I was thinking of dropping it in src/compiler/spirv
02:06jekstrand: jenatali: It'd have to be a separate library with separate deps, though.
02:07jenatali: Makes sense - if you want to go for it I'm happy to review it, otherwise I'll get to it... eventually
02:09airlied: jekstrand: ah anv never recycles command buffers which explains why you don't see the loader magic issue
02:10jekstrand: jenatali: I feel like we've had this conversation before but how much do you care about API stability in clc_compiler.h?
02:11jenatali: jekstrand: It's not critical - both components will always have the same ship vehicle, it's just they live in separate codebases, so they can always be rebuilt together
02:12airlied: ah radv hits the sme bug
02:20jekstrand: jenatali: What's this vec hint buisiness?
02:21jenatali: jekstrand: It can be queried from the API: https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_KERNEL_ATTRIBUTES
02:22jenatali: We don't do anything else with it currently
02:25HdkR: anholt: Surprising someone wanted to land SSE optimizations in the pi driver. I would have expected the driver to already be thunked to the host variant
02:25HdkR: but I guess it could imporve the thunkless path
02:26jekstrand: jenatali: Ah
02:27jenatali: jekstrand: IIRC older versions of the CL API spec specifically call out a small handful of attributes that can be queried - I think it's just thread group size, thread group size hint, and vec hint
04:04jekstrand: dcbaker: meson can't find clang. Any ideas?
04:11jljusten: jekstrand: can't say I know anything about it, bit I wonder if --cross-file on https://docs.mesa3d.org/meson.html might help
04:18jekstrand: No, libclang, not the compiler.
04:18jekstrand: Well, yes the compiler, but in lib form.
04:19dcbaker: With cmake or not cmake?
04:21jekstrand: dcbaker: it's trying cmake
04:24dcbaker: It needs to be capitalized on Linux because cmake
04:26dcbaker: I have an mr to use cmake for clang in clover that's open
04:26jekstrand: dcbaker: link?
04:29jekstrand: dcbaker: I see now.
04:29jekstrand: dcbaker: It's claiming I'm trying to get invalid targets
04:32jekstrand: dcbaker: Not even clangBasic is on the list
04:32dcbaker: Uhhhh, that seems broken
04:33jekstrand: Run-time dependency clang found: NO
04:33jekstrand: ../meson.build:299:0: ERROR: Dependency Clang not found: CMake: invalid module clangBasic for Clang.
04:33jekstrand: Try to explicitly specify one or more targets with the "modules" property.
04:33jekstrand: Valid targets are:
04:33jekstrand: ['LLVMDemangle', 'LLVMSupport', 'LLVMTableGen', 'llvm-tblgen', 'LLVMCore', 'LLVMFuzzMutate', 'LLVMIRReader', 'LLVMCodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter', 'LLVMMIRParser', 'LLVMGlobalISel', 'LLVMBinaryFormat', 'LLVMBitReader', 'LLVMBitWriter', 'LLVMBitstreamReader', 'LLVMDWARFLinker', 'LLVMExtensions', 'LLVMFrontendOpenACC', 'LLVMFrontendOpenMP', 'LLVMTransformUtils', 'LLVMInstrumentation',
04:33jekstrand: 'LLVMAggressiveInstCombine', 'LLVMInstCombine', 'LLVMScalarOpts', 'LLVMipo', 'LLVMVectorize', 'LLVMObjCARCOpts', 'LLVMCoroutines', 'LLVMCFGuard', 'LLVMLinker', 'LLVMAnalysis', 'LLVMLTO', 'LLVMMC', 'LLVMMCParser', 'LLVMMCDisassembler', 'LLVMMCA', 'LLVMObject', 'LLVMObjectYAML', 'LLVMOption', 'LLVMRemarks', 'LLVMDebugInfoDWARF', 'LLVMDebugInfoGSYM', 'LLVMDebugInfoMSF', 'LLVMDebugInfoCodeView',
04:33jekstrand: 'LLVMDebugInfoPDB', 'LLVMSymbolize', 'LLVMExecutionEngine', 'LLVMInterpreter', 'LLVMJITLink', 'LLVMMCJIT', 'LLVMOrcError', 'LLVMOrcJIT', 'LLVMRuntimeDyld', 'LLVMTarget', 'LLVMAArch64CodeGen', 'LLVMAArch64AsmParser', 'LLVMAArch64Disassembler', 'LLVMAArch64Desc', 'LLVMAArch64Info', 'LLVMAArch64Utils', 'LLVMAMDGPUCodeGen', 'LLVMAMDGPUAsmParser', 'LLVMAMDGPUDisassembler', 'LLVMAMDGPUDesc',
04:33jekstrand: 'LLVMAMDGPUInfo', 'LLVMAMDGPUUtils', 'LLVMARMCodeGen', 'LLVMARMAsmParser', 'LLVMARMDisassembler', 'LLVMARMDesc', 'LLVMARMInfo', 'LLVMARMUtils', 'LLVMAVRCodeGen', 'LLVMAVRAsmParser', 'LLVMAVRDisassembler', 'LLVMAVRDesc', 'LLVMAVRInfo', 'LLVMBPFCodeGen', 'LLVMBPFAsmParser', 'LLVMBPFDisassembler', 'LLVMBPFDesc', 'LLVMBPFInfo', 'LLVMHexagonCodeGen', 'LLVMHexagonAsmParser', 'LLVMHexagonDisassembler',
04:33jekstrand: 'LLVMHexagonDesc', 'LLVMHexagonInfo', 'LLVMLanaiCodeGen', 'LLVMLanaiAsmParser', 'LLVMLanaiDisassembler', 'LLVMLanaiDesc', 'LLVMLanaiInfo', 'LLVMMipsCodeGen', 'LLVMMipsAsmParser', 'LLVMMipsDisassembler', 'LLVMMipsDesc', 'LLVMMipsInfo', 'LLVMMSP430CodeGen', 'LLVMMSP430Desc', 'LLVMMSP430Info', 'LLVMMSP430AsmParser', 'LLVMMSP430Disassembler', 'LLVMNVPTXCodeGen', 'LLVMNVPTXDesc', 'LLVMNVPTXInfo',
04:33jekstrand: 'LLVMPowerPCCodeGen', 'LLVMPowerPCAsmParser', 'LLVMPowerPCDisassembler', 'LLVMPowerPCDesc', 'LLVMPowerPCInfo', 'LLVMRISCVCodeGen', 'LLVMRISCVAsmParser', 'LLVMRISCVDisassembler', 'LLVMRISCVDesc', 'LLVMRISCVInfo', 'LLVMRISCVUtils', 'LLVMSparcCodeGen', 'LLVMSparcAsmParser', 'LLVMSparcDisassembler', 'LLVMSparcDesc', 'LLVMSparcInfo', 'LLVMSystemZCodeGen', 'LLVMSystemZAsmParser', 'LLVMSystemZDisassembler',
04:33jekstrand: 'LLVMSystemZDesc', 'LLVMSystemZInfo', 'LLVMWebAssemblyCodeGen', 'LLVMWebAssemblyAsmParser', 'LLVMWebAssemblyDisassembler', 'LLVMWebAssemblyDesc', 'LLVMWebAssemblyInfo', 'LLVMX86CodeGen', 'LLVMX86AsmParser', 'LLVMX86Disassembler', 'LLVMX86Desc', 'LLVMX86Info', 'LLVMXCoreCodeGen', 'LLVMXCoreDisassembler', 'LLVMXCoreDesc', 'LLVMXCoreInfo', 'LLVMAsmParser', 'LLVMLineEditor', 'LLVMProfileData',
04:33jekstrand: 'LLVMCoverage', 'LLVMPasses', 'LLVMTextAPI', 'LLVMDlltoolDriver', 'LLVMLibDriver', 'LLVMXRay', 'LLVMWindowsManifest', 'FileCheck', 'llvm-PerfectShuffle', 'count', 'not', 'yaml-bench', 'LTO', 'LLVMgold', 'llvm-ar', 'llvm-config', 'llvm-lto', 'llvm-profdata', 'bugpoint', 'dsymutil', 'llc', 'lli-child-target', 'lli', 'llvm-as', 'llvm-bcanalyzer', 'llvm-c-test', 'llvm-cat', 'llvm-cfi-verify', 'llvm-cov',
04:34jekstrand: 'llvm-cvtres', 'llvm-cxxdump', 'llvm-cxxfilt', 'llvm-cxxmap', 'llvm-diff', 'llvm-dis', 'llvm-dwarfdump', 'llvm-dwp', 'llvm-elfabi', 'llvm-exegesis', 'llvm-extract', 'llvm-gsymutil', 'llvm-ifs', 'llvm-jitlink', 'llvm-link', 'llvm-lipo', 'llvm-lto2', 'llvm-mc', 'llvm-mca', 'llvm-ml', 'llvm-modextract', 'llvm-mt', 'llvm-nm', 'llvm-objcopy', 'llvm-objdump', 'llvm-opt-report', 'llvm-pdbutil', 'llvm-rc',
04:34jekstrand: 'llvm-readobj', 'llvm-reduce', 'llvm-rtdyld', 'LLVM', 'llvm-size', 'llvm-split', 'llvm-stress', 'llvm-strings', 'llvm-symbolizer', 'llvm-undname', 'llvm-xray', 'obj2yaml', 'opt', 'Remarks', 'sancov', 'sanstats', 'verify-uselistorder', 'yaml2obj', 'intrinsics_gen', 'omp_gen', 'acc_gen', 'diagtool', 'clang', 'clang-format', 'clang-offload-bundler', 'clang-offload-wrapper', 'clang-scan-deps',
04:34jekstrand: 'clang-rename', 'clang-refactor', 'clang-cpp', 'clang-check', 'clang-extdef-mapping', 'clang-apply-replacements', 'clang-reorder-fields', 'modularize', 'clang-tidy', 'clang-change-namespace', 'clang-doc', 'clang-include-fixer', 'find-all-symbols', 'clang-move', 'clang-query', 'pp-trace', 'clangd', 'libclang', 'clang-tablegen-targets']
04:37dcbaker: What version of llvm/clang do you have?
04:37zmike: is this the 2021 version of "mods are asleep, post cflags" ?
04:38jekstrand: dcbaker: 11
04:39dcbaker: I'm still using 10, I'll switch to 11 tomorrow and see if I see the same thing. Unless someone beats me to it
04:39dcbaker: Sure looks like they've changed their cmake though
04:39HdkR: 12 is in RC candidate status as well
04:40dcbaker: Try clang-cpp and see if that's all you need
04:40dcbaker: Or libclang
04:40dcbaker:is just making it up
04:40airlied: on fedora it should link
04:42jekstrand: No, it's definitely Clang
04:42jekstrand: Unless there are two different packages to install
04:42jekstrand: But clover builds fine so that can't be the problem
04:42airlied: assumning you have clang-devel installed
04:43airlied: oh if clover builds then it's just meson fun to cut-n-paste from clover :-P
04:44jekstrand: airlied: Yeah, but I'm trying to cut-n-paste from dcbaker. He's supposed to be the expert. :P
04:45dcbaker: Nah, but I played one on TV once
04:55vsyrjala: "the (meson) expert" 0% on rotten tomatoes cause it was just some guy typing on a keyboard for two hours
05:07jekstrand:has hacked it sort-of successfully, maybe
05:32jekstrand: dcbaker: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9156
05:32jekstrand: dcbaker: Please make it all better. :)
05:48DrNick: huh. the Portal 2 Vulkan renderer uses DXVK
05:49hifi: didn't the opengl renderer also use something similar that valve developed?
05:54DrNick: oh, yeah, libtogl.so does have a lot of exported C++ classes with names starting with IDirect3D9
08:05tzimmermann: danvet, do you have an idea where to begin with the udl dma fix?
08:10danvet: tzimmermann, tbh no idea
08:10danvet: tzimmermann, is it just a warning, or stuff fails?
08:10tzimmermann: danvet, it fails
08:11danvet: maybe ask airlied to escalate the regression
08:11tzimmermann: x11 display for udl remains black
08:11danvet: like it's all nice to cleanup dma-api and be annoyed about what drm drivers do, but breaking stuff for refactoring isn't ok
08:11tzimmermann: danvet, yes
08:11tzimmermann: but it's two late now
08:11danvet: hm why?
08:12tzimmermann: it's in v5.9-rc3 already
08:12tzimmermann: the problem is at https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_prime.c#L630
08:12danvet: we can't back it out?
08:12danvet: yeah it's the wrong device
08:12tzimmermann: we can revert, but i expect a flamewar
08:13danvet: yeah hch isn't reasonable in this regard unfortunately :-(
08:13danvet: which is why I think airlied and me should maybe send some mails around
08:13danvet: but I have plenty of fireworks already
08:13danvet:not in the mood for more
08:14tzimmermann: danvet, don't worry. i just want to discuss the problem with you :)
08:14danvet: tzimmermann, ok an idea
08:14tzimmermann: by wrong device, youmean that the dev pointer points to the non-udl device?
08:14danvet: drm_gem_prime_import_dev <- use this one
08:15danvet: and for the device, simply chase parent device pointers until you spot something that's has a dma mapping attached (if we can detect that)
08:15tzimmermann: with the other device?
08:15danvet: even better if you can directly ask the usb subsystem for the host device
08:15tzimmermann: good idea
08:15tzimmermann: the usb controller should have dma support
08:15danvet: but if that's not available, hack together something horrible with walking upwards until you hit a pci_device
08:16danvet: if not, we can't import
08:16danvet: I think at least
08:16danvet: well actually no
08:16danvet: if the host controller doesn't have dma support
08:16danvet: we can still import
08:16danvet: but only with dma_buf_vmap and cpu access only
08:17danvet: and no dma_buf_attach
08:17tzimmermann: that was my question: for udl, do we actually need to call the dma_map_sgtable ?
08:17danvet: which unfortunately means a pile of rework all over drm_prime.c to support that
08:17danvet: I dunno
08:17tzimmermann: udl does not do any dma
08:17danvet: if we never feed the sg_list into the usb stack, then no
08:17danvet: and only vmap is needed
08:18tzimmermann: that was my plan so far. but maybe the idea with using the controller's dma is a better one
08:18danvet: I'm kinda wondering whether some of the spi tiny panel drivers have the same problem
08:18tzimmermann: no idea
08:19danvet: tzimmermann, I do think it would be good to have a hw-less import support in drm_prime.c
08:19danvet: but it's some work
08:19danvet: because we use the attachement pointer for import caching
08:19tzimmermann: whereever i look, things fall apart :/
08:19danvet: for udl?
08:20tzimmermann: for everything: generic fbdev, vmap locking, now udl
08:20tzimmermann: danvet, well at least i have an idea for a fix. thanks a lot
08:21danvet: I do think it's substantially more robust now, but yeah all that changing causes stuff to break
08:21danvet: and we have no CI at all
08:27HdkR: The matrix users were never heard from again
08:35vsyrjala: they'll be back, in black trench coats, dark glasses, and armed to the teeth
08:39pq: but like ghosts or holograms, they just flicker in and out and pretty much never do anything - thanks matrix.org's irc bridge instance for being so popular
08:41Venemo: flickering like a hologram? is that a new mesa feature?
09:14MrCooper: zmike: normally, one should wait for feedback at least one business day before merging an MR (there are people living around the globe :)
09:25Venemo: why do the load_tess_level NIR intrinsics exist? why aren't these just normal input loads?
09:30HdkR: "You hear that, Mr. Anderson? That's the sound of inevitability, that's the sound of your death, goodbye, Mr. Anderson"
09:30Venemo: lol, HdkR :)
09:31Venemo: the funny thing is that I can't find anything that actually creates these intrinsics either. I think TTN is the only place where they are created?
09:52Venemo: hmm, looks like glsl_to_nir can add them either as inputs or as system values
09:53Venemo: I guess maybe it generates these intrinsics when it is a system value?
09:59Sumera[m]: danvet: sent the patch for skipping all vblank. would you like me to send in the other patches for skipping wait_vblank_count now, or just send it along with other upcoming fixes for the crc tests?
10:00danvet: Sumera[m], I think we need to figure out first how crc are supposed to work on this hw
10:00danvet: so probably needs more experimentation of what works for basic crc tests before we go ahead with a specific approach
10:01danvet: Sumera[m], what I noticed from your logs is that e.g. the crc setup function reads a crc just to make sure it works
10:01Sumera[m]: danvet: yep, that makes sense
10:01danvet: and that never completes if there's not a vblank that keeps crc updated every frame
10:02danvet: so I think we have a bit a fundamental problem on what to do
10:02danvet: either we fake more crc in the kernel driver (seems a bit silly)
10:02danvet: or we skip all these dummy crc reads (uh lots of work probably all over igt)
10:02Sumera[m]: yeah, I think we will have to tweak vkms
10:02danvet: or we inject some fake flips on the crtc to generate a crc, which is also not going to be very clean
10:03danvet: I think for now digging around to figure out how big the problem is would be good
10:04Sumera[m]: why can't we make vkms just assume crc is updated every frame?
10:04Sumera[m]: or is that what faking crc is?
10:04danvet: but the thing is, that kinda happens we have vblank automatically
10:04danvet: but here we try to fake vblank-less mode
10:05danvet: so in a way there's nothing that regularly updates stuff
10:05danvet: and so unchanged crc is the right thing conceptually
10:11melissawen: danvet, Sumera[m], and if we just fake one crc capture whenever request to set the crc source as a "proof of crc work" ?
10:11danvet: melissawen, yeah, maybe that works too
10:11danvet: but it's a bit quirky
10:12danvet: since for vkms we need to do an atomic_commit
10:12danvet: so quite some machinery in the kernel
10:12danvet: and in a way the same thing userspace is supposed to do when it wants to update the virtual display by calling the DIRTYFB ioctl
10:12danvet: so I'm wondering whether we should call that from igt everywhere we need a crc update
10:13danvet: but that's also a pile of work
10:13danvet: it's a bit tricky I think
12:06mripard: tzimmermann: if you're bored, my drm_atomic_state series could use some review. vsyrjala reviewed some parts of it, but pinchartl only gave is acked-by for the rcar changes
13:26tzimmermann: mripard, i'll have a few minutes later today. i'll take a look
13:29mripard: I just sent the new version, there's no rush
13:29mripard: (it's also fairly big)
13:37pq: Lyude, do you know of the kernel S-o-b policy being changed? Your comment on https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/556#note_807705 would be nice.
13:54zmike: MrCooper: if you're referring to my recent zink branch merges, I've previously discussed this matter with zink reviewers and everything is working as planned
13:55danvet: pq, Lyude I think defacto it's dont ask, wont tell in the kernel wrt pseudonyms :-/
13:56pq: danvet, that's what I thought but I was conviced otherwise on this channel when pseydonyms were discussed.
13:58danvet: I mean in practice insisting on real names doesn't work, but it's also formally required at least in the kernel for reasons I wasn't involved in when that discussion happened
13:59pq: that's why I would be interested to see what happens to the patch that suggests changing the kernel's guideline
13:59danvet: epic bikeshed most likely, at best
14:00danvet: I think we could do something for all fd.o projects, if there's a ready-made DCO that sucks less in this regard
14:01pq: what do you mean by ready-made DCO?
14:01danvet: probably shouldn't draft this ourselves
14:02danvet: the value in documents like this is largely standardization imo
14:02danvet: kinda like coc
14:02pq: I assumed the problem was, can one sign anything (e.g. a DCO) with a pseudonym.
14:02pq: as the DCO exists already: https://developercertificate.org/
14:03pq: maybe Linux Foundation would know
14:03danvet: oh I got confused
14:04danvet: I thought DCO had some real name policy in there, but reading it again I don't see anything like that
14:05danvet: pq, where did you find that part with no pseudonym?
14:06danvet: where in docs
14:08pq: danvet, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n405
14:08danvet: ah yes found it
14:09danvet: frankly I'd write that off as lkml being lkml like usual
14:09danvet: really doesn't look like a DCO requirement
14:09danvet: definitely not anything I ever enforced on dri-devel
14:09pq: heh, cool that you agree
14:10danvet: least because utf8 is still not enough to hold all names for real people out there, so whatever you put there is fine
14:10danvet: just not only the email address alone
14:11danvet: and even that is kinda for practical reasons, because people move companies and stuff like that, but their community reputation sticks with their "name"
14:16pq: yes, yes, all these practical reason are kind of obvious, but I was wondering if some lawyer had said "s-o-b without a real name is useless in my country"
14:17danvet: ime the stuff LF lawyers produces is fairly useless and in many cases caused substantial uproar
14:17pq: eh heh
14:17pq: yet, is there any other reason to use S-o-b at all than lawyers?
14:18danvet: minimal due dilligence
14:18danvet: we have some $process to make sure we're not knowingly merging code we don't have a license for
14:18danvet: it's not going to protect against a real supply chain attack ofc
14:18danvet: but I mean if someone wants to spend 2 years to build up reputation so they can sneak a backdoor in
14:18danvet: do it
14:19danvet: that's way better bug ratio than the stuff I produce :-)
14:21danvet: pq, I think the key thing (in my layman understand) is that the DCO process establishes intent
14:21danvet: so if someone is nasty and sneaks something in, and then laters sues
14:22danvet: they acted with malicious intent, and generally the law does not look kindly on that
14:22danvet: also in copyright there's a big difference between willful and accidental infringement
14:23pq: danvet, what you say makes perfect sense to me. Yet for some reason the kernel doc is what it is...
14:27danvet: pq, yeah kernel doc also removed maintainer's responsibility to ensure coc is enforced and a pile of other things we should maybe not blindly follow :-)
14:28pq: (I was also interested whether Lyude can be contacted via Gitlab mentions at all, since no word for a week)
14:29pq: or I found a wrong lyude in gitlab
14:33Peste_Bubonica: I'm running mesa 21.0-r4, and at least for my use case, its rock solid. Do you guys think that a rc-5 will be released, or a 21.0.0 stable on the way?
14:33danvet: pq, you got the right Lyude
14:39tzimmermann: mripard, i looked through the series. all patches seem to have an r-b or a-b. is there something specific you want me to review?
14:43mripard: tzimmermann: all the a-b from pinchartl are only for one driver, not for the whole patch
14:44tzimmermann: ah, ok
14:44mripard: (i'm not sure how to make that explicit in the patch)
14:44danvet: mripard, add # for rcar-du
14:44danvet: or just dont and then blame it all on pinchartl when it blows up :-)
14:46mripard: I was going to do the latter, but he played it smart and preemptively said on IRC he wouldn't take the blame :)
14:47pinchartl: danvet: I'll do my best to ignore the blame when it comes ;-)
15:17emersion: is there a helper to figure out whether a DRM format is RGB in the kernel?
15:17emersion: is !is_yuv enough?
15:18emersion: or are there non-YUV non-RGB formats?
15:20pq: emersion, hmm... is C8 RGB to you or not? :-)
15:22emersion: i have no idea :P
15:22pcercuei: could be packaged YUV too
15:23pcercuei: You really fit what you want in the palette
15:24emersion: amdgpu doesn't support it, so i'm safe for now
16:21anholt: MrCooper: does it sound likely to you that we can't just move the test-source-dep driver blocks to the drivers because of the changes: *mesa_core_file_list and friends?
16:40MrCooper: anholt: ah, yeah, YAML anchors are only valid within the same file :(
16:40anholt: ok, that's what I was thining
16:40anholt: so I backed out the test-source-dep movs
16:40anholt: now it's just the yml in that MR
16:40MrCooper: didn't think of that
16:41anholt: then I can move expectations after
16:41anholt: test-source-dep changes pretty infrequently
16:48jekstrand: Do executables have build shas?
16:49anholt: jekstrand: not by default but you can pass the arg to have it included
17:01kisak: dcbaker: even if mesa 21.0.0 isn't ready to leave rc status, can you cut a 21.0.0-rc5 when you have some spare time?
17:02kisak: s/rc5/rc5 release/
17:12dcbaker: kisak: yup, I'm already working on that
17:13kisak: cool, thanks
17:15Lyude: pq: huh? I thought I already responded to that
17:15Lyude: I said I'm not really sure if anyone is pushing for changing the policy on psuedonyms
17:18Lyude: ...huh, it says my comment is "pending"
17:18Lyude: oh-it never posted lol, weird
17:21emersion: need to atomic commit these GitLab comments
17:45daniels: Lyude: 'add comment now' does what it says on the box; the tempting green 'start review' button queues your comment up to post when you finish your review
17:47Lyude: ah, gotcha
19:04alyssa: does Gallium document the semantics of what's supposed to happen if `surf->format != surf->texture->format`?
19:05imirkin: surf->format is supposed to happen.
19:05imirkin: happens with a view
19:06alyssa: alright.. if there's already content in surf->texture, does that get reinterpreted (no conversion) or converted? reinterpreted, I think?
19:07alyssa: ack, thank you
19:07alyssa: and that makes the test pass, wee :)
19:10alyssa: ..while regressing other tests because 2 bugs make a right
19:28imirkin: alyssa: sounds like BE issues to me...
19:28imirkin: just have to swap endianness an even number of times
19:28imirkin: and all wrongs are righted
19:47pq: Lyude, thanks!
19:51jekstrand: jenatali: Piles of hacks but I now have a little binary that eats up OpenCL C and dumps out Intel binaries in the from of .h files one can include. :D
19:52jenatali: jekstrand: Nice!
19:52jekstrand: I should probably add xz support one day but meh
19:54jenatali: jekstrand: Want me to take a look at wiring up the static path for opencl-c.h?
19:54jekstrand: jenatali: I think my MR now mostly has a static path but it's going to take some meson hackery to get it right
19:55jenatali: jekstrand: Yeah mainly just what we have in the microsoft\clc dir though, right? Should just be a matter of wiring it up to an option like we did for libclc?
19:56alyssa: jekstrand: Do you uh plan to check in those .h files? :<
19:56jekstrand: jenatali: There were issues with the meson. The way you're detecting clang doesn't work on my distro for some reason.
19:57jenatali: jekstrand: Oh I see. Considering I've only tried it on Windows, where we have to use a just-built Clang that's not terribly surprising...
19:57jekstrand: Also, I've not yet bothered to hook up a proper enable for when the dep is required.
19:58jekstrand: alyssa: No, I plan to build them as part of the compile.
19:58alyssa: jekstrand: Looking forward to your meson witchcraft for that ;)
19:59jekstrand: alyssa: It's not too bad
20:03dcbaker: jekstrand: something's either wrong with fedora or with your install
20:03dcbaker: I can using clang11 with cmake finder, as long as I capitalize "clang"
20:16jekstrand: dcbaker: Maybe I need newer meson?
20:16jekstrand: Nah, that shouldn't be it
20:16dcbaker: what version do you have?
20:17jekstrand: some git version
20:17jekstrand:just has a meson checkout somewhere
20:18jekstrand: dcbaker: Ok, looks like with recent meson it works
20:19jekstrand: Nope. Spoke too soon
20:19jekstrand: dcbaker, ajax: I don't know what's busted. All I know is that it doesn't find Clang
20:20jekstrand: dcbaker: Fails with latest ToT meson
20:23airlied: jekstrand: but if clover works what is going wrong?
20:23airlied: at least on fedora lately clang is built into one shared lib
20:23jekstrand: airlied: Clover detects clang completely differently from the standard meson "find clang" thing
20:23airlied: I expect the meson one is trying to find static libs the shared lib is a new thing
20:24dcbaker: that's probably it
20:24airlied: but fedora clang-devel ships cmake bits
20:24jekstrand: could be
20:25dcbaker: is that clang-cpp?
20:25airlied: dcbaker: yes /usr/lib64/libclang-cpp.so.10
20:26anholt: ajax: getting around to the fxt move so that swrasts won't fail at it
20:26dcbaker: sigh, why do the LLVM projects hate their users so much that they have to make finding the static libs completely different than the shared libs?
20:27airlied: dcbaker: it's their users that cause it, since lots of people only want to link against subsets of the whole thing
20:27jekstrand: Which makes sense for static, I guess
20:27ajax: anholt: nice! no rush, obviously.
20:28dcbaker: sure, but why can't you write your cmake in such a way that asking for subcomponents still get's you clang-cpp
20:31airlied: asking why and cmake is never going to result in happiness
20:31dcbaker:is resigned to that
20:32dcbaker: in general asking "why is your build system stupid?" doesn't end with hapiness
20:34airlied: it does look like you pick clang-cpp as a target or you pick targets as a target
20:36dcbaker: should we tie static clang to static llvm?
20:37jekstrand: I'm happy to tie staticness together
20:37ajax: i wanna say almost certainly? i can't imagine wanting either of (static,dynamic) for one and not the same for the other
20:37jekstrand: You may want LLVM but not clang but if you have both, you're going to want them to be linked the same way.
20:37ajax: someone wants that they can write the patch
20:37dcbaker: this is fair
20:40alyssa: dcbaker: hey, while I have your attention can you either r-b or nak !8893 so I can land or close it? I don't like having too many MRs just sitting open :?
20:45dcbaker: alyssa: that seems fine with me, maybe anholt or someone from igalia or pengitronix can say whether it makes sense for etnaviv or vc*?
20:45alyssa: I added all the labels! :p
20:58dcbaker: jekstrand: I updated my PR, I think it will work for you now
20:58dcbaker: Nixos apparently has both the static and shared libs, which is extremely convenient
21:00jekstrand: dcbaker: Which PR? The one for Clang via cmake detect?
21:02jekstrand: dcbaker: Nope
21:02jekstrand: dcbaker: Oh, wait...
21:04jekstrand: dcbaker: Can we have one centralized dep_clang, please?
21:05jekstrand: Or better yet, maybe we should just get all the CLC stuff common and keep it there.....
21:05jenatali: jekstrand: One dep_clang sounds good to me
21:05dcbaker: either way, I thought you were trying to put all that stuff in one place ;)
21:05jekstrand: dcbaker: I'm trying to get us closer.
21:06jekstrand: dcbaker: I'm not sure how motivated I am to move clover over to the common code.
21:06jekstrand: Maybe I can con karolherbst (who doesn't seem to be on IRC these days) or airlied to do it. :)
21:07dcbaker: jenatali: I can do it, the only thing to figure out is the difference between the two module lists
21:08jenatali: dcbaker: Assuming you meant to tag jekstrand :)
21:09dcbaker: well, I mean to tag both of you separately.
21:09dcbaker: the list of modules between clover and microsoft clc is pretty similar
21:09jenatali: Ah, true
21:09dcbaker: but there's a couple in each that's unique, do you mind overlinking? or should I try to add logic to sort them out?
21:10jenatali: Overlinking should be fine, we should only pull in bits from the modules that are needed
21:11jenatali: As long as they're actually built - we currently build a trimmed down list of modules so we might not have everything that Clover needs
21:11jenatali: though, I did manage to get Clover to build against my Clang at one point so we probably do
21:12jekstrand: dcbaker: I suspect the "right" thing to do is to make my common CLC MR work for both Linux and Windows.
21:12dcbaker: gah, and now I need a Meson feature I've known I should have fixed by now and haven't ☹️
21:12jekstrand: Then we can move clover to it eventually and drop the current clover stuff.
21:12dcbaker: sounds like a plan
21:12jekstrand: I don't mind if the current clover stuff is "fixed" before we drop it.
21:12dcbaker: for now then I'm going to leave my MR as-is and we can go from there
21:13jekstrand: Ok. Would you mind applying whatever you did to your MR to my MR?
21:13jekstrand: Just throw patches on top. It'll all have to be squashed in the end.
21:27mattst88: 21-02-19 21:26:58 ERROR - dEQP error: SPIR-V WARNING:
21:27mattst88: 21-02-19 21:26:58 ERROR - dEQP error: In file ../src/compiler/spirv/spirv_to_nir.c:1074
21:28mattst88: 21-02-19 21:26:58 ERROR - dEQP error: Decoration not allowed on struct members: SpvDecorationInvariant
21:28mattst88: 21-02-19 21:26:58 ERROR - dEQP error: 1204 bytes into the SPIR-V binary
21:28mattst88: I've seen that locally too. known regression?
21:28zmike: I saw "SPIR-V WARNING" and immediately rushed to the log to see what I broke because I'm so used to seeing that during zink testing
21:31anholt: mattst88: sounds like an existing warning
21:31anholt: we don't error out our tests for stderr complaints, lots of vulkan drivers end up with stderr spam from vtn during the cts
21:31mattst88: okay. maybe I'm only noticing it because I silenced a bunch of other fprintf spew from my deqp runs
21:32anholt: restrict is another favorite one that gets complained about
21:32jenatali: I'm trying to dig into https://gitlab.freedesktop.org/mesa/mesa/-/issues/4050, where somehow Dolphin apparently causes our driver to try to do front buffer rendering, and I'm having trouble even figuring out where start digging :( Any ideas?
21:34alyssa: Dolphin *shrug*
21:36zmike: emulators shrug
21:38jekstrand: mattst88: Known glslang bug
21:38jekstrand: mattst88: That's never been fixed
21:38mattst88: jekstrand: okay, thanks
21:39jekstrand: Feel free to fix it. :P
21:39jekstrand: And by "fix it" I don't mean make our SPIR-V parser not warn. I mean fix glslang. Just want to be clear. :)
21:40jekstrand: zmike: Is Zink now a more conformang GLSL -> SPIR-V path?
21:41zmike: jekstrand: what's your reference for "more" in this case?
21:41zmike: jekstrand: totally unrelated, !9113 needs your expert review
21:41jekstrand: zmike: ¯\_(ツ)_/¯
21:45zmike: btw nobody else look at that MR, zink is 100% conformant and that's all you need to know
21:46alyssa: Khronos would like a word.
21:47zmike: uh, well, mr khronos, sir, uhh, wha-nice to hear from you!
21:48Sachiel: is this khronos guy the one from khronos trigger?
21:49zmike: no, that's crono, we're talking about guy from dragonball z--goku's short friend
21:54alyssa: chrono? clockman?
21:56jekstrand: jenatali: Looking at the clover stuff, it doesn't look like it'll be easy to move over to share with clc. It's very tightly intertwined with the LLVM compile path used by old AMD clover.
21:57jenatali: jekstrand: :(
21:57jekstrand: We just need to delete the non-NIR path
21:58jekstrand: "just"... heh.
21:58alyssa: jekstrand: Any commit deleting non-NIR has my r-b ;P
21:59anholt: ajax: let's see what https://gitlab.freedesktop.org/anholt/mesa/-/pipelines/273686 says
21:59jekstrand: I think someone probably has to finish r600 NIR first.
22:02jekstrand: jenatali: I don't see you setting the clang language version anywhere. Am I mising something?
22:02jenatali: jekstrand: Language version?
22:02jenatali: I didn't write that Meson so I'm not super familiar with it
22:02jenatali: Or are you talking about in the invocation?
22:02alyssa: Does... anyone use AMD+LLVM+clover?
22:03jekstrand: Oh, I see. clover sets it via C++ and you set it via strings.
22:03jenatali: jekstrand: Oh right. We originally were using Clover's approach but I found it much simpler to set the strings and let the logic inside the parameter parsing set everything up for me
22:06Thaodan: Hey I have a AMD 6900 XT and recently got some shutdowns because of overheat (amdgpu 0000:03:00.0: amdgpu: ERROR: GPU over temperature range(SW CTF) detected!) how can I debug if this was true or bug in the driver?
22:07emersion: last time this happened to me i forgot to plug in the GPU fan after re-assembly
22:08Thaodan: The gpu was in high use at that time (4k gaming)
22:08Thaodan: Well the fan was defenetly plugged in, I did not deassembly it so far (want to equip a waterblock later)
22:09Lyude: i'd stress test the card and see if you can reproduce the issue
22:09emersion: i guess you could query the temp readings
22:09Lyude: and yeah - keep an eye on the thermal sensors
22:10Lyude: tbh some of the older amd cards were pretty well known for doubling as toasters, so it's definitely not unlikely it could be an issue with your setup dispersing heat
22:11Lyude: I know my r9 380 is almost never below 50°C just while it's idling with my displays turned on, it's always been a hot card
22:11Lyude: (still works pretty well though, minus the one performance issue I need to bisect upstream)
22:12jenatali: Ugh, I think I found my Dolphin bug... apparently they swap buffers without the framebuffer bound, which means we don't flush, so later on we flush rendering to the surface that was the back buffer but is now the front buffer :(
22:12Thaodan: Lyude: It's the latest AMD card
22:12Lyude: ooooh ok, yeah those are usually a lot better with heat
22:13Lyude: it's still definitely worth stress testing it and keeping an eye on the thermal sensors, it could be an issue with airflow in your case or something (if you take the side of your chassis off and the temperature drops pretty significantly, you probably need more case fans :)
22:13Thaodan: : AMD SIENNA_CICHLID (DRM 3.40.0, 5.10.15-pf12-1, LLVM 13.0.0) (0x73bf)
22:15ccr: so .. if it runs too hot, does it become burnt sienna? :P
22:18Thaodan: I thought there is maybe something similar too https://gitlab.freedesktop.org/drm/amd/-/issues/1267 but for RNDA2
22:20Lyude: i'd just test your setup first before blaming the driver tbh
22:28bnieuwenhuizen: I'd say check if your fan ramps up while it is getting hotter
22:29Lyude: oh - yeah that's another good point
22:29Lyude: if it doesn't -then- it's probably a bug
22:31Thaodan: Doing that and with vkmark and gputest the fans run up and work no issue
22:31jenatali: Well, I guess this is my reason to implement Win32 TLS. Apparently this bug is because one thread ends up unbinding the context from another, because it's before Mesa realizes that the app is multithreaded
22:32Thaodan: I had the issue while using wine with vkd3d no clue if that could be related
22:33Thaodan: I also had a kernel panic in the amdgpu drivers hours ago before that happened: https://paste.opensuse.org/3438225
22:34Thaodan: Not sure if that is related
22:34Lyude: looks like a modesetting bug related to displayport with amdgpu, probably unrelated
22:41Thaodan: Everything fine
22:43Lyude: Thaodan you might want to try something that's more focused on really stressing it out and not just benchmarking, like UNIGINE
22:43Lyude: and leave it running for a while until the temperature appears to have flatlined (e.g. it's gotten as hot as it seems like it's going to get, and is no longer rising)
22:59Thaodan: Ran Unigine Superposition 4k and 8k back to back no issue
23:57Lyude: Is 80 still the default column limit for the kernel? I had thought that we bumped it up to 100