01:07 veggiesstand: you think it was my actions you got all banned from #freenode? you think I do something special with irc code, above that I know only what tcp protocol sends? all the code comes from china and rest of the world to spam victim playing terrorists, I guess I am not the only one bothered about your terror , so even here you are wrong you fucking idiots. I deal with defending my life for 35
01:07 veggiesstand: years in a row reaching at 41 already, and deal with legal works unlike you, I get help to publish how real code works in contrast to your trash.
03:47 mephi: This might be a dumb question but, does anyone know why the header files in MESA/src/gallium/frontends/rusticl have no include guards?
04:01 airlied: mephi: I think they are only used with bindgen
04:03 mephi: I see, thanks
04:44 mlankhorst: airlied/sima: Wanted to do a double pull request, but seems -fixes is not yet on same base
04:44 mlankhorst: so you only get 1. :)
04:53 nobodynoticed: my lines is something I do not rely on, nobody kills bastards for me it seems, I have to kill the British and local and Finnish abusers all by myself and wait the world war to begin to do that, I am not Russian sided either, only their doctors and Chinese have done medicating that they promised to do, Estonian I do not consider myself to be, those are the freaks who started the
04:53 nobodynoticed: worldwide scams, right through the courts documenting own inventions -- did not expect me to ask for recording, Estonia is such scammers it's sick down to infrastructure, but I burn them all, it would be nice if japanese, Chinese or south-koreans help me in Cambodian region with the terrorist parasites there. you thought you abuse me for 15 years by fun and none notices I assumed as
04:53 nobodynoticed: much as none really know or have seen you are idiots total nutbolts from the head?
05:40 DavidHeidelberg:think that some people are really annoying oranges...
06:00 airlied: mlankhorst: -fixes only had things I already have last I looked anyways
08:20 Trevorolla: I gave all my powers and effort to help you, and that's how you treat me, so I try the last time, on may13 polderan said something on dri-devel and later of freedeskto channels, does it help if you organize all instructions that roll down to the same bank to envision how compiler should really work, cause you can access multiple banks values whatever batch/group queries at compiling so
08:20 Trevorolla: that's tremendously fast if you specify a container or structure for the answer sets and instructions, and I later meant that yes Bitcoin mining takes advantage of multithreading but doing it from same context is troublesome, it's bad idea, you ask for trouble like vulkan does, do it separate ctx since memory is cheap, compress the memory according to the algorithm finally given to you,
08:20 Trevorolla: then there's so much memory that you see it's not worth to do such trouble askings. but overall I take care of my own things, appears you are poisoning me and yourself and others with your abuse, it's intoxicating.
08:36 blabberguy: batch compilation is where you specify many answers per cell and all operands to reorganize the cell, it's maybe good for illustration it's like multibank symbolic execution that is compiled time reorganizing indexing.
08:36 blabberguy: but that's my last suggestion
08:37 blabberguy: not sure what or where to you see those troubles you envision
11:49 lumag: mripard, I've reviewed generic parts of the HDMI patchset. the rest is the drivers part.
12:44 cwabbott: gfxstrand: zmike: has anyone tried making vk_properties::pCopySrcLayouts be const
12:45 zmike: konstantin: ^
12:45 cwabbott: having to cast to non-const or declare a static but not const array in the driver feels a little dirty
13:24 mripard: lumag: awesome, thanks a lot
14:56 tzimmermann: sima, airlied, there's an unmerged drm-misc-fixes PR from last week. do you merge -fixes PR's during the merge window? https://lore.kernel.org/dri-devel/20240516072658.GA8395@linux.fritz.box/
14:59 sima: I guess it got lost in all the regression frenzy :-/
15:00 sima: tzimmermann, want me to pick it up right away?
15:01 tzimmermann: sima, only if i'm expected to send a PR this week
15:02 tzimmermann: if it's not supposed to be merged this week anyway, it wouldn't matter
15:06 sima: nah we merge those ofc, they're fixes
15:08 tzimmermann: sima, ok. please merge it then and i'll send out the next PR today
15:08 sima: hm it's a backmerge, but doesn't look like has any new conflicts
15:10 sima: tzimmermann, sometimes backmerges during the merge window are too messy and we delay it all (because really should never backmerge a random point from the merge window)
15:11 sima: script is running now, I'll ping you when it's pushed
15:18 tzimmermann: thanks
15:37 gfxstrand: cwabbott: I
15:37 gfxstrand: cwabbott: I don't think anyone has tried. I'd be happy to see it happen
15:38 sima: tzimmermann, airlied pushed
15:52 tzimmermann: thanks a lot sima
16:56 gfxstrand: cwabbott: I don't think anyone has tried. I'd be happy to see it happen
16:59 konstantin: cwabbott: It's probably not going to happen because of vk_set_physical_device_properties_struct
17:00 gfxstrand: konstantin: I don't follow
17:02 konstantin: I guess we can just add a const cast to vk_set_physical_device_properties_struct. The point is that vk_properties isn't read only.
17:03 gfxstrand: There's literally only one user of that function. I'm happy to tell Venus their weird and special.
17:05 gfxstrand: I'm pretty sure that's actually broken in venus right now
17:06 gfxstrand: It never allocates storage for them AFAICT so it's memcpying to NULL
17:06 konstantin: They do not support the extension yet, I think.
17:07 gfxstrand: Yeah but I think it's fine to just disable that extension in the codegen since Venus needs to special-case it anyway
17:07 gfxstrand: Then we can make them const and everything is fine
17:07 gfxstrand: In the vk_set_physical_device_properties_struct codegen, to be specific
17:09 konstantin: makes sense
18:48 HdkR: Should the DirectX-Headers subproject be doing a shallow clone? I've noticed periodically that github starts serving me like 100KB/s when cloning that repo
18:49 jenatali: HdkR: Probably
19:22 daniels: HdkR: please send an MR!
19:24 dwfreed: shallow clones are more expensive for GitHub than full clones
19:24 jenatali: I'm on it
19:24 jenatali: :O really?
19:24 dwfreed: (ask chocolatey about that one)
19:24 dwfreed: yeah
19:25 HdkR: So we can make our experience better AND force github to do more work? Sounds like win-win
19:26 dwfreed: oh wait, it wasn't chocolatey but cocoapods
19:26 dwfreed: https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193772935
19:28 HdkR: So the issue is doing a shallow fetch and then doing subsequent non-shallow fetches
19:28 jenatali: Yeah that's what it looks like
19:31 jenatali: !29361
19:39 kisak: mattst88: follow up from yesterday. my llvm 15/17 LLVM_MAX_SLOT trouble isn't relevant anymore llvm.eclass got replaced with llvm-r1.eclass and that's using a different LLVM_SLOT mechanism to explicitly select one llvm version.
19:39 kisak: ^for the build
19:40 kisak: Pushed my old cruft aside and giving a fresh mesa-9999 ebuild a try.
22:33 janesma: has anyone else noticed i915 begins numbering devices at /dev/dri/card1? it used to start with card0. I notice it on linux 6.8 and later.
22:38 dumperdriver: so for the obnoxious tomato's like DavidHeidelberg the showdown of compilation that's actually needed is first binary rewriter for asm to write indexes of instructions for operand 1 and operand 2 and the alu dictionary answer sets get accessed, it appends the indexes cause the linear algebra of polderan method to store and access compressed integers in this case reordering them by
22:38 dumperdriver: reading access to another hash to store but changing the order works on vectors too it's 4 instructions per entire block to translate, through possibly parametrized constants. so ding ding ding, you are wrong apes. I am a more sane version of a developer, you are obnoxious tomatoes without braincells. so after the reordering alus get called through the two operand indexes where as
22:38 dumperdriver: dependent ones are made adjacent and called by succeeding index in the same bank, for an example src1 + src2 indexes1 is in 1025-2048 range and index2 is in 3072-4096range in pseudo code would if replaced by 2+2 would access 1025+2 and 3072+2 is x at compilation from all of the sorted banks, and with vector linear algebra on polderan method stored back at adjacent for every aluop. so on
22:38 dumperdriver: os those offsets and indexes also are manipulated based of the operand types, if it's io as in with syscalls it uses fixed annotations, technically the compiler is dad easy, that is why I deal with such code it's at the same time carrying maximum efficiency.
22:55 dwfreed: "dad easy"
23:11 iive: janesma, i think that udev is the one assigning device numbers. It could be e.g. initrd starting udev, then restarting with rootfs copy