00:35jenatali: FYI karolherbst, finally made it to the test_thread_dimensions CL CTS test, and found this warning in the source: "WARNING: kernel reported CL_OUT_OF_RESOURCES, indicating the global dimensions are too large. Skipping this size."
00:36jenatali: So, we could probably get by without local work group ID offsets if you'd prefer not to have them in the system values group and we could avoid looping dispatches in our runtime, though since it's implemented I'm inclined to keep it
00:38jenatali: Also karolherbst and jekstrand, if I wanted to go about implementing printf, I'm curious your opinion on what the right representation of a variadic intrinsic would be in NIR :)
00:38karolherbst: to ignore it :p
00:38karolherbst: I think I would ... use ... ufff
00:38karolherbst: how many args can it have?
00:38jenatali: I'm still considering it to be optional, but I don't think it's that hard to implement in the runtime
00:38jenatali: Unlimited I think
00:39karolherbst: jenatali: maybe make it special and use variables
00:39karolherbst: new instruction type
00:39karolherbst: and it references one array with the args
00:39karolherbst: and one string, which is also a variable :p
00:39jenatali: Yeah, was thinking about that. Something similar to tex where it can have variadic number of sources
00:39karolherbst: just have a varaible
00:40jenatali: It can have multiple strings, %s args are allowed
00:40karolherbst: allthough.. uff
00:40karolherbst: this is so stupid
00:40jenatali: Though was going to reconstruct those on the host side
00:40karolherbst: maybe a struct with different types?
00:40karolherbst: like packing the values as a struct or so
00:40jenatali: %s args at least have to be constants in the SPIR-V data
00:40jenatali: That's a possibility
00:40karolherbst: so char[n]
00:41karolherbst: I think building a fitting struct type should be feasible
00:41karolherbst: and allows us to reuse nearly everything
00:41jenatali: Yeah I actually think I like that
00:42jenatali: Thanks :)
00:42karolherbst: then the first arg is a deref to a uint8_t for the format string and the second arg a deref to a struct containing the params
00:42jenatali: Yeah, that works
00:43karolherbst: and then add a lowering pass doing the magic :p
00:43jenatali: Yeah, exactly
00:44jenatali: FYI it's looking like we're pretty close to full CL1.2 conformance (minus printf + single-context-multiple-device)
00:45jenatali: Just have to actually get all of our work upstream :P
01:03mattst88: someone with ops want to ban him?
01:20karolherbst: mattst88: last time somebody did this, that person forgot to remove the ban later again :p
01:20mattst88: and nothing of value was lost, in all likelihood :)
01:22karolherbst: yeah.. no idea what to think about somebody saying stuff like this
01:22jenatali: Now I feel like I missed out
01:23karolherbst: jenatali: you probably don't see those join/leave messages like I don't?
01:23karolherbst: or you see them or just ignore those :p
01:23jenatali: Oh yeah I have those turned off
01:23karolherbst: but apparently some people think it's worth banning people for that
01:23karolherbst: some like broken clients and rather ban people than fixing their clients :p
01:23karolherbst: but I expressed this opinion a few times already
01:24karolherbst: detecting connection issues and hiding those messages for those would be _sooo_ hard to do in clients
01:24mattst88: most people just get banned with a message telling them to ping the person who put the ban in place
01:24mattst88: not a big deal
01:25HdkR: irssi's knockout command is useful for this, since it'll automatically unban after the time period
01:25karolherbst: yeah... I don't like this "moral high ground" behaviour though
01:25karolherbst: but maybe I am not old fashioned enough for that
01:25imirkin: it's super-annoying.
01:26karolherbst: yeah.. but could be solved through fixing lcients
01:26imirkin: right. so everyone could change, or one person could change.
01:26mattst88: imirkin: in fact, you have op powers in this channel :)
01:26imirkin: i do?
01:26karolherbst: well... there is not just a single person with connectivity problems
01:26mattst88: according to /msg chanserv access #dri-devel list
01:27imirkin:feels the power
01:27imirkin: now how do i do this... he insta-quits, so i can't really send him a message.
01:28mattst88: msg chanserv AKICK #dri-devel ADD diddledan you should fix your connection | private op info
01:28jekstrand: jenatali: Uh.....
01:29jekstrand: jenatali: We have nothing like that in NIR. We also don't have strings.
01:30jekstrand: jenatali: texture instructions take a variable number of arguments.
01:30jenatali: jekstrand: Yeah, I know. My plan was just to reflect the format string and any string arguments out to the runtime during compile (they have to be compile constants) and then just write out the rest of the data (32 or 64 bits at a time) into a buffer
01:30imirkin: mattst88: i'm not cool enough for akick apparently
01:30imirkin: so he just has the ban. a bit sad.
01:30mattst88: imirkin: oh, strange
01:30mattst88: in any case, thanks for that
01:31imirkin: and i have no way of messaging him since he's literally insta-quitting
01:32imirkin: o well.
01:32mattst88: he'll figure it out
01:32karolherbst: spam it :p
01:33jekstrand: jenatali: One thought that occurs to me would be to actually represent it as a string of instructions, each of which handles a single operand.
01:34karolherbst: also two things "you should fix your connection" makes it sound person is responsible even though the ISP or the application could be crap, second I wouldn't think I would ever get banned due to having connection issues.... but maybe assuming what others can do or might think is the new way of dealing with other people.. dunno... maybe I am just alone with my views here
01:34imirkin: that's equivalent to people saying "i didn't do it, my IDE did"
01:35jenatali: jekstrand: I was figuring I'd end up lowering it to that. The trick is, I should reserve one continuous buffer range for a single printf call and then write all the args, so it's essentially "printf for number of size_t-sized args" followed by a number of "printf arg" instructions
01:35karolherbst: who cares... saying "banned due to connection issues" is not harder than "you should fix your connection" :p
01:36karolherbst: just trying to be open minded towards not coming around as a bad person
01:36karolherbst: some might be fine either way
01:36karolherbst: some might not
01:36karolherbst: and being "logical" here won't do any good either
01:42mattst88: karolherbst: sounds like you're pissed that someone banned you once because you kept disconnecting :)
01:42karolherbst: didn't happen to me yet :p
01:42mattst88: I don't think anyone's saying he's a bad person
01:42jekstrand: jenatali: I was thinking something along the lines of a chain of intrinsics where you'd have a printf_start which gets consumed by a sequence of printf_append intrinsics, each of which takes the previous instruciton in the chain as its first source and the data to append as it's second source and, finally, the chain is terminated by a printf_print instruction.
01:42karolherbst: that's not what I meant
01:42mattst88: and like imirkin said, he was disconnecting so fast we couldn't send him a message
01:43karolherbst: but depending on the phrasing the one banning could come around as one
01:43jekstrand: Each append could take some information about formatting in the const indices
01:43karolherbst: mattst88: well.. I managed to get whois information on that nick
01:43jenatali: jekstrand: Hm, that's a really interesting idea
01:43karolherbst: so sending a message is also possible :p
01:43karolherbst: just needs a few tries
01:44jekstrand: jenatali: As long as you're guaranteed that the lowering code can read the whole chain, it should be possible to do the lowering.
01:44mattst88: this is just kind of how it's done on IRC. I don't really know what to tell you. there's no malice involved
01:44jenatali: jekstrand: Not sure I really want to do the printf format string parsing in the compiler though. Was really just planning to put the raw args in a buffer and run a pretty plain printf on the host
01:44karolherbst: mattst88: I already said that "logical" reasning here doesn't do any good
01:44jekstrand: jenatali: Right...
01:44karolherbst: most people might be fine with it
01:44karolherbst: maybe 99% would be
01:44karolherbst: but then you have those few might getting annoyed or something
01:45karolherbst: just.. be careful about the phrasing
01:45mattst88: are you that 1% or are you playing devil's advocate for that 1%? :)
01:45karolherbst: devils advocate :p
01:45jekstrand: jenatali: If you're planning to do more work on the host then you really just need to write out some data.
01:45jenatali: jekstrand: Yeah, exactly. I mean I definitely have to work on the host if I want it to show up in stdout :P
01:45jekstrand: jenatali: Right.
01:45jekstrand: jenatali: You just need to do it atomically somehow.
01:46jekstrand: Well, pseudo-atomically
01:46karolherbst: but I seriosuly believe that IRC clients could get fixed so it's not annoying to anybody :p
01:46jenatali: jekstrand: Yep. Was thinking after lowering it'd be an atomic increment of a size counter, followed by a sequence of individual writes of the data to print
01:46karolherbst: and it's quite sad that most clients still don't
01:46jekstrand: jenatali: Yup. That's what I was thinking too
01:47jenatali: jekstrand: Just need to find the right intermediate so I can lower it to that easily :) Unless you want the raw NIR representation to look like that straight away
01:47jekstrand: jenatali: Maybe that's how it should be represented? Have a printf_start intrinsic which takes a number of arguments or maybe a size and returns a pointer. Then you write to the pointer.
01:47jekstrand: It can be a struct with the different argument types in it.
01:48karolherbst: mattst88: also "that's how it always was like" is a very bad and nothing saying argument :p please don't use it anymore
01:48jenatali: jekstrand: Yeah that's what karolherbst was suggesting, a printf intrinsic taking a struct - that's a number of arguments, a size, and their types all in one
01:48mattst88: karolherbst: ... *and* nothing has changed to invalidate the argument
01:50karolherbst: besides the point...
01:50mattst88: Is it?
01:50mattst88: okay, karolherbst says it is, and so it is.
01:50karolherbst: it assumes those "community rules" were perfect from the start
01:50karolherbst: which they are not
01:50kallisti5: hey.... I'm super out of date. What's the process to approve PR's ?
01:50karolherbst: but :p
01:50karolherbst: you know that yourself
01:50kallisti5: Any docs anywhere?
01:51karolherbst: so saying that is like saying "we don't want to improve"
01:51jekstrand: jenatali: It could just be a printf_write intrinsic which takes a pointer. That'd be super-simple.
01:51mattst88: karolherbst: lol, wow, I didn't expect this to set anyone off like this
01:52mattst88: karolherbst: I suggest that you invest some time in fixing the problem in you're as concerned about the current solution as you appear to be
01:52karolherbst: yeah... maybe I should fix all the clients.. honeslty thought about it already
01:52jenatali: jekstrand: Yeah, seems pretty simple to be honest. I'll probably give it a shot. Not sure when, since it's not high priority from our side but I feel dirty asking for waivers for features I know I can implement
01:52karolherbst: but that's just one issue and a minor one
01:52imirkin: karolherbst: fwiw, i _like_ seeing when people enter and leave
01:53karolherbst: imirkin: sure, and I don't disagree
01:53karolherbst: but clients could hide it for people having obvious connection problems
01:53karolherbst: just a random thought
01:53jekstrand: jenatali: Sure. The more I think about it, the more a simple printf_write intrinsic which takes a pointer to a struct seems like the right idea.
01:53kallisti5: oh man, I hate it when mom and dad fight
01:53jenatali: Great, seems simple enough, thanks :)
01:54karolherbst: or maybe.. clients say "$nick has conection troubles"
01:54jekstrand: The struct type would neatly encode all the argument type information and then you'd just have to make some lowering which calculates the size, does the atomic, and then copies the bits of data one by one form the struct pointer.
01:54jenatali: jekstrand: Yup. Just need to figure out the right way to represent %s args so that it can be reported from the compiler rather than at runtime
01:55karolherbst: jenatali, jekstrand: could even use ssbo stuff for the transfer of data then.. just copy the struct out ;)
01:55kallisti5: imirkin: if a non-dev submits a pr, and I do a code review.. are we just commenting Reviewed By and merging?
01:55karolherbst: uhm... global memory stuff in this case
01:56imirkin: kallisti5: i don't know anything about the non-email-based process.
01:56karolherbst: having a "hidden" global* arg for the buffer
01:56kallisti5: imirkin: ah. wahwah. Thanks :-) As of a few months ago I was still git emailing :-)
01:56jenatali: karolherbst: Yeah, exactly. For us at least a global* arg is just a SSBO, so yeah it's just do an atomic at the beginning of the buffer, then write to an offset
01:57imirkin: kallisti5: i still do if i'm looking for feedback.
01:57karolherbst: jenatali: is there any strict ordering?
01:57karolherbst: I guess not
01:57kallisti5: imirkin: any idea who would be a good person to ping to get the low-down?
01:57karolherbst: but.. the spec could be annoying
01:57imirkin: kallisti5: you literally picked the worst person
01:58imirkin: everyone-but-me is all gung-ho on gitlab
01:58jenatali: karolherbst: "In the case that printf is executed from multiple work-items concurrently, there is no guarantee of ordering with respect to written data."
01:58karolherbst: okay.. cool
01:58kallisti5: airlied: ya got any docs on the gitlab process?
01:58karolherbst: so we could have a uint32_t being the size with an atomic inc of the additional one to reserve and then just write out the data or something... but yeah
01:58karolherbst: I guess that should work then
01:59jenatali: karolherbst: Yep that was my idea for what it'd get lowered to
01:59karolherbst: jenatali: the formats are compile time constants, right?
01:59jenatali: karolherbst: Yes, along with any %s args
01:59karolherbst: I am wondering if we should just index the strings and add the data
01:59mattst88: kallisti5: docs/submittingpatches.html in mesa
01:59karolherbst: would be pointles copying the strings into the buffer over and over again...
02:00karolherbst: but maybe that simplifies the runtime
02:00kallisti5: mattst88: thanks :-)
02:00jenatali: karolherbst: Nah, was originally thinking I'd just take the SPIR-V string SSA IDs, but I don't really want to propagate those through NIR. But something similar
02:00kallisti5: mattst88: as a maintainer I should likely know this :-|
02:01karolherbst: jenatali: well.. maybe we can just put everything into the buffer when launching the kernel and have a preset offset... and then the GPU just adds the data
02:01karolherbst: then we have everything we need inside the buffer
02:02karolherbst: and the kernel is under our control here anyway, so we can deal with it properly
02:02jenatali: karolherbst: Hm, maybe. Seems complex when dealing with multiple different printfs in the same kernel
02:02kallisti5: mattst88: oh.. ok. So Reviewed-By in comments, then merge
02:02karolherbst: jenatali: strings are just ids then
02:02karolherbst: and we would have a simple table at the begining of the buffer mapping id to real strings
02:03mattst88: kallisti5: yep, merge by assigning the MR to Marge-Bot, which does the rebase/test/merge
02:03karolherbst: and each kernel has its own table so to speak
02:03kallisti5: mattst88: oh. glad you said that. was about to merge
02:03jenatali: karolherbst: Hmm. Yeah, something like that. I'll think about it a bit more. Not sure the right way to reflect that though - I don't want to have the kernel write the string to a buffer on every thread
02:04karolherbst: jenatali: no, the CPU prefills the buffer when the kernel gets launched
02:04karolherbst: just to keep everything together
02:04kallisti5: mattst88: wait... I can commit directly to Mesa/DRM, but I can't assign Marge-Bot
02:04jenatali: If the CPU already knows the strings, I don't see the point of putting them in the buffer
02:04karolherbst: so the runtime doesn't need to do weird buffer to kernel to string lookups as everything is already in the buffer
02:04jenatali: Oh, ok I guess that makes sense
02:04karolherbst: but no idea if that's a real benefit or if we can ignore it
02:05mattst88: kallisti5: hm, I would have thought those were the same permissions
02:05jenatali: That's not a problem for the way the CLOn12 runtime is set up at least
02:05karolherbst: just a random though to make it really easy to parse those buffers
02:05mattst88: kallisti5: I can assign to Marge for you
02:05kallisti5: mattst88: thanks :-) https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/75
02:05kallisti5: added my Reviewed-By
02:06karolherbst: jenatali: yeah.. more wondering about corner cases like crashing GPU contexts and stuff
02:06karolherbst: but even then the runtime should know...
02:06jenatali: karolherbst: Somehow I doubt that printf is super important in the case of GPU crashes... eh though I guess that could be considered one of the primary reasons to use it
02:07karolherbst: useful for driver devs as well maybe
02:07jenatali: But yeah I'm just going to focus on passing the test first ;)
02:07kallisti5: mattst88: actually.. maybe Haiku's web browser just isn't rendering the drop down properly
02:08mattst88: kallisti5: ohh, libdrm. I don't think libdrm uses Marge, so you can just merge that with the button on gitlab
02:08kallisti5: mattst88: ah. ok. That makes even more sense :-)
02:09mattst88: kallisti5: annoyingly, to apply the R-b you have to check out his branch, git commit --amend, git push, etc
02:09mattst88: tbh, for libdrm, that's not worth it
02:09mattst88: clicking the button is enough :)
02:09kallisti5: mattst88: yup. working as expected :-)
02:10kallisti5: We have a dev interested in migrating Haiku's graphics drivers to drm compatibility layer like FreeBSD
02:10kallisti5: so, playing around to see how much work it's going to be
02:18airlied: kallisti5: does haiku expose anything like drm device nodes?
02:28kallisti5: airlied: our drivers are still modeled like the BeOS ones. We have kernel drivers which present device nodes in a device tree (/dev/graphics/radeon_hd_080000)
02:28kallisti5: then, we have "accelerants" which implement all the card calls to do modesetting / acceleration / etc via ioctl's to the drivers
02:34kallisti5: we have a long way to go :-) At the moment, we have a functioning llvmpipe.. but pretty much zero 3d accel because of Be's "unique design" Still undecided if it is going to help us or hurt us in the long-run.
02:35airlied: yeah I expect a redesign to be more like linux/dri might help it :-P
02:35kallisti5: haha. I wrote our radeon_hd driver. It actually works pretty well for mode-setting. (and the code is cleaner than Linux's :-))
02:36kallisti5: but yeah. One guy can't maintain "all of it".. we're lacking enough people to develop for multiple graphics cards
02:38kallisti5: trying to ride on drm is a lot easier now-a-days with wayland in the mix. Last time I looked at this stuff in 2011, X11 was *deep* into mesa + drm
08:32linusw: I have a problem applying a fix on drm-misc-fixes since it is not rebased on v5.8-rc1, anyone knows how to fix this?
08:32linusw: I don't know if I would have permissions to rebase it and push myself, maybe I do?
08:34mripard: linusw: we never rebase drm-misc branches
08:35mripard: but otherwise, for requests like that, pinging either mlankhorst_, tzimmermann or myself on IRC (depending on who's in charge of that branch for that release) is the right thing to do :)
08:36linusw: mripard: OK shall I just merge v5.8-rc1 into the drm-misc-fixes branch like I see you did for v5.7-rc1?
08:36mripard: tzimmermann will do it
08:37tzimmermann: linusw, you need -rc1 merged into drm-misc-fixes?
08:37tzimmermann: how urgent is it?
08:38linusw: tzimmermann: pretty urgent not because the fixes are urgen but because I am going on vacation and in two weeks the fixes will be more urgent...
08:39linusw: tzimmermann: I can merge it in but just nervous that I might screw something up.
08:39tzimmermann: linusw, if i do the merge tomorrow, would this work for you?
08:39linusw: tzimmermann: should be fine
08:40tzimmermann: linusw, ok. i'll let you know then
08:42linusw: tzimmermann: thanks!
10:05pendingchaos: jekstrand: is the issue that the meaning of restrict isn't clear when an intrinsic has several possible resources?
10:05pendingchaos: and that the patch propagates restrict to the intrinsics (this seems to be done for OpenGL without spirv, but I think each access can only have one resource there)
10:05pendingchaos: for some reason, I thought SPIR-V -> NIR already propagated restrict to intrinsics
10:49clever: how commom is it for DRM drivers to support an h-sync interrupt being routed to userland or involved in page-flip type operations?
10:53MrCooper: not sure what you're asking; are you wondering about which drivers / apps / other circumstances it can happen with, or something else?
10:56clever: i know that the hw supports it, more wondering if its something DRM can typically expose down to userland, i can see it being tricky, because i also need to know which scanline the change will happen at, before i update the framebuffer
11:00MrCooper: I don't know of it being exposed to userspace directly; and actually even for "asynchronous" page flips, at least AMD GPUs have a dedicated interrupt source for page flip completions, the drivers don't use the h-sync interrupt for that
11:02clever: yeah, this hw has ~9 interrupts, for the front/sync/back/active, on both v and h axis's
11:02clever: and the driver is currently setup to only use the v-frontporch-start interrupt
11:03clever: so you get an interrupt after the full field has been scanned out, and you have a few scanslines (front-porch dependant) before vsync even begins
11:57danvet: tzimmermann, oops :-/
11:57danvet: do you have a patch for the oops fix already, or should I type one?
12:12clever: ah, i can also confirm that the hw can report the current scanline, so i could do what i want, if the kernel was extended a bit
12:20tzimmermann: danvet, i don't have a patch. i only reverted it locally for now
12:28danvet: ok I'm typing
12:28danvet: a bit unfortunate that we have such a huge pile of patches on top now :-/
12:28danvet: also I guess wrong, I expected to break the render drivers, not display :-/
12:29danvet: tzimmermann, https://paste.debian.net/1152157/
12:31tzimmermann: danvet, not quite. you have to change the conditional to if (!private). or set obj->filp for private objects.
12:34dolphin: airlied, danvet: -rc1 time, CI lighted up due to ext4 warn that was applied to CI topic branch
12:34danvet: tzimmermann, https://paste.debian.net/1152158/ better?
12:34dolphin: shall I do a quick push and then immediate force-push without the fix to get CI results, last time somebody caught the middle state
12:35dolphin: so there was the for-CI patch momentarily applied to drm-intel-fixes
12:35danvet: dolphin, since we do pull requests with tags that shouldn't matter?
12:35danvet: or am I confused about what blew up last time around?
12:36dolphin: nah, just somebody grabbed the tree in the transient state where the fix is applied
12:36tzimmermann: danvet, i don't know what the correct solution is and don't have the time to test this ATM. but at least the segfault should be gone. i'd test it tomorrow
12:36dolphin: it had some conflicts etc.
12:43pq: bernie_, yeah, not sure I've actually looked at that yet, but that's what I'm helping to get upstreamed in a different form.
12:45pq: bernie_, "single master" is not a problem unless you are doing ditry hacks. "relaxing single master" *is* a problem.
12:50ivyl: emersion: Patchwork - I have now "more info" page linked in the strange/incomplete series message, e.g. https://patchwork.freedesktop.org/series/78214/#rev2
12:50ivyl: If there's anything missing there let me know
12:53emersion: typo: "you are better of" → off
12:53ivyl: spelling, my greatest enemy :-)
12:55emersion: looks good!
12:56ivyl: sweet, thanks for giving it a read
13:02danvet: tzimmermann, thx, I'll send it out
13:16karolherbst: trying to get fully rid of having to handle derefs inside nouveau but we still required them from builtin shaders: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/798a15196434341d188f2d73c90cc4159a4ed38c
13:16karolherbst: anybody objections to this? or should the driver simply lower that?
14:01kallisti5: airlied: hey! drm is compiling on Haiku. That was actually pretty easy
14:01kallisti5: now, we just have to do "everything else"
14:02agd5f_: kallisti5, what do you mean "drm stuff"? The parser hasn't changed in years
14:04kallisti5: agd5f_: oh. sorry, took me a second to catch up :-) previously drm wasn't in the atombios parsers
14:05kallisti5: aka, with a few ifdef's it would compile on non-Linux platforms.
14:05kallisti5: i'm kind of shifting my focus back to porting drm to Haiku... so a more moot point now :-)
14:07kallisti5: airlied: I submitted the Haiku patches here: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/78 honestly, the current drm codebase is looking great. The fact that I could port it to a new OS with only 3 patches is pretty amazing. in 2011 it would have been a *LOT* worse.
14:35jekstrand: pendingchaos: roughly, yes.
14:36pendingchaos: I think I'll try to change the patch so that it doesn't propagate the access flag then
14:36pendingchaos: it shouldn't be too difficult for ACO to search for the nir_variable instead
14:39jekstrand: We don't typically create nir_variables for SSBOs but I guess we could.
14:41pendingchaos: how does the deref path work then? casted from a vulkan_resource_index?
14:43agd5f_: kallisti5, also 0x6fdf is a valid polaris ID
14:45pendingchaos: it looks like SPIR-V -> NIR already create a nir_variable for a SSBO: https://pastebin.com/raw/S2hYsy1G ?
15:03karolherbst: do we have a function in nir to extract the constant part of an ssa value?
15:06jekstrand: karolherbst: nir_src_is_ssa
15:07jekstrand: karolherbst: nir_src_is_const, rather
15:07jekstrand: karolherbst: Then nir_src_as_uint()
15:07jekstrand: or nir_src_as_float or nir_src_as_bool or nir_src_as_int
15:07jekstrand: take your pick
15:07karolherbst: jekstrand: I meant if it's a result of an iadd or something
15:07karolherbst: and one source is a constant
15:07karolherbst: .. but maybe I can just check for that add
15:07jekstrand: karolherbst: We don't have a helper directly for that
15:07jekstrand: karolherbst: But, nir_ssa_scalar is your friend there.
15:08jekstrand: karolherbst: That mostly helps with doing the chasing and getting swizzles correct
15:10karolherbst: jekstrand: we can encode a constant part in our tex instructions
15:10karolherbst: so you can have a+indirect
15:15karolherbst: uhh.. I think image lowering is broken
15:15karolherbst: or rather.. we don't handle aoa that well
15:15karolherbst: writeonly uniform image2D tex;
15:15karolherbst: imageStore(tex[n], ivec2(gl_FragCoord.xy), color);
15:15karolherbst: and I get a constant offset of 1 not 2
15:20karolherbst: jekstrand: mind looking over it and verify it looks broken? https://gist.github.com/karolherbst/de2f134246dc69278f6f19626635b967
15:20karolherbst: second is after gl_nir_lower_images
15:21karolherbst: ssa_35 should be ssa_34 + 2 not + 1
15:22karolherbst: mhh.. maybe setting size and align to always be 1 indeed breaks aoa
15:36kallisti5: agd5f_: ok. Just checking. Looked like that ID may have been a typo
15:36kallisti5: (last one, random jump, etc)
15:52danvet: tzimmermann, people already want to push bugfixes to drm-misc-fixes, I cced you on the thread
16:01jekstrand: karolherbst: Yeah, that looks busted.
16:01jekstrand: karolherbst: Maybe we don't have very good tests for that?}
16:16karolherbst: jekstrand: we have one piglit tests ... but I didn't run the CTS with image lowering enabled
16:16karolherbst: just ported nouveau away from derefs
16:43clever: how does DRM typically handle VBI for composite outputs, at a driver level?
16:43clever: the current method i'm seeing is a bit of a hack, just messing with front/back porch timings, to cause the active area to shift up some, so image data bleeds into VBI, then rendering into that region
16:44pendingchaos: jekstrand: I've updated !5207 and it should now only apply restrict to variables and not the intrinsics
16:44clever: but the hw is capable of having a dedicated plane in the VBI area, and the driver can just offset the other planes down, and make it invisible
16:46karolherbst: ehh... a2bb7b26a1c4
17:00vsyrjala: clever: there is no standard api for stuffing data into the vbi. dunno if some driver expose some ad-hoc stuff for it
17:03clever: vsyrjala: ive heard that v4l has an api for it, but it feels a bit weird to have a random vbi node in /dev/ for a certain drm connector
17:06tzimmermann: danvet, ok. i talked to linuxw today. i'll merge -rc1 tomorrow and the patch can land then
17:13karolherbst: I think I fixed most of the remaining issues with images in nir vs TGSI here, so would be nice if somebody could take a look as well: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5480
17:14karolherbst: should allow every driver to disable PIPE_CAP_NIR_IMAGES_AS_DEREF without regressions
17:14vsyrjala: clever: we could always expose some props for this in drm. the hard part is making sure those props make sense and are a) actually useful b) generic enough that most drivers could expose them. though i expect the number of other people interested in cvbs outputs is ~0
17:18imirkin: vsyrjala: so ... 4294967295 people are interested in cvbs output? :)
17:19vsyrjala: overly optimistic estimate?
17:19clever: vsyrjala: depending on how far you want to take it, you could make it as basic as a 2nd plane in the VBI area, to as complex as just accepting 45 bytes per scanline (750 bytes total), and generating the graphical encoding in-kernel
17:20clever: vsyrjala: its complicated by wanting to be able to render to VBI, while not interfering with normal "single master" drm stuff, and letting xorg or qt use drm diretly, without it being aware of the vbi stuff
17:21vsyrjala: never really looked too hard into what various hw allow you to stuff in there
17:22imirkin: are there hw encoders for that sort of thing? given that scanout is done from a single framebuffer, would have to be an overlay plane maybe? but those can be variously limited too.
17:22clever: vsyrjala: in the case of the rpi, the hw is very flexible, and lets you freely control the front/sync/back/active timing, for both the v and h axis
17:24clever: so if you reduce the backporch and increase the frontporch/active, the total scanlines remains the same, but the active lines bleed into the vbi
17:24seanpaul: sravn: re "drm/mipi_dbi: Convert pr_debug calls to DRM_DEBUG_DRIVER" those call sites don't have access to drm_device, is best practice to call drm_dbg(NULL, "blah")?
17:25vsyrjala: omap2 at least had a dedicated register for wss data, so for the supporting something like that the interface would have to be fairly high level
17:26vsyrjala: but now i have a feeling that either pal or ntsc actually wanted the wss in the active portion of the signal
17:27clever: vsyrjala: if your wondering, https://zxnet.co.uk/teletext/recovery/good.jpg the bottom is the VBI data from 4 fields, that was recovered from a VHS tape
17:39sravn: seanpaul: drm_dbg(NULL, ...) will fail as drm_device is dereferenced unconditionally. Today there is only two options. DRM_DEBUG_XX() or dev_dbg(). We have no drm_xxx variants that do not take a drm_device *
17:41seanpaul: sravn: ah, right, i was looking at the NULL check in drm_dev_dbg which downgrades to printk but overlooked the (drm)->dev in the macro, i was wondering if that's what you wanted me to do from your review feedback. sounds like it's fine as-is
18:07sravn: seanpaul: yup, in general we should use drm_* logging when we can, but there are a lot of cases where we do not have any drm_device. bridge drivers and panel drivers for example
18:08sravn: I had made an attempt once to come up with drm_* loggin with no drm_device but the idea was rejected. We need to majority of the DRM_* users migrated over first
18:09sravn: Said patch was full of bugs, but thats another story :-)
18:21airlied: kallisti5: libdrm is only a small helper librsry, all the work is in the kernel and mesa
19:12anholt_: kusma: how does one preview docs changes in the current pipeline?
19:15kusma: anholt_: I usually build locally, using sphinx-build. But you can also trigger a build on the CI in your own fork. But https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5469 will block that option without modifocations...
19:17anholt_: kusma: build in my own fork sounds great, but I don't see anything to click in my pipeline
19:18kusma: anholt_: It will only build from master right now, so you'd have to push there
19:18kusma: anholt_: or change the only-statement in the pipeline config
19:19kusma: anholt_: Patches welcome ,-)
19:19kusma: anholt_: But, generally speaking, I would recommend building locally. It's fast and easy. "sphinx-build -b html docs public" :)
19:20kusma: (if you don't have sphinx, "pip3 install sphinx sphinx_rtd_theme")
19:22anholt_: kusma: once you run the pipeline, where does it end up?
19:27anholt_: I guess just click your way through the artifacts?
19:41clever: is there an api in libdrm, to get the names for connectors?
19:44airlied: clever: connectors dont have names, they have type and index
19:45clever: which enum is the type in? the struct just calls it an int
19:45airlied: but i dont think the type enum has a strings attached
19:46danvet: CosmicPenguin, robclark just pointed me at https://www.irccloud.com/pastebin/OpOze0ox/
19:46clever: airlied: i can add my own, if i know which enum to read
19:46danvet: I need to know what's behind msm_ioctl_gem_submit+0x634 since obviuosly my audit from 92ec076771079 didn't catch it
19:46danvet: or newly added
19:47clever: airlied: but the struct just says: `uint32_t connector_type; uint32_t connector_type_id;`
19:47airlied: clever: drm_mode.h
19:47airlied: clever: the types are defined
19:47airlied: you just cant use enums across ioctls
19:48clever: `#define DRM_MODE_CONNECTOR_DSI 16 ` well, its not even an enum, heh
19:49clever: that might also be a driver bug, its reporting the DPI as DSI
19:49airlied: i think we wanted to move to panel for all those
19:50airlied: its not really interesting to userspace dsi vs dbi etc
19:50clever: there are also some tricky situations, the official rpi touchscreen, is a DPI panel on a DSI->DPI adapter chip
19:50clever: so its a DSI port, but a DPI panel
19:50clever: what would drm call that?
19:51danvet: yeah hence panel connector type and done
19:51danvet: userspace really shouldn't care beyond that
19:51clever: danvet: id call it DSI, because thats the port i plug the display into
19:51kusma: anholt: gitlab pages, under your name
19:51clever: the adapter is considered part of the display, and no board exists to use it on DPI
19:52clever: anholt_: ah, ive seen your name in a lot of the commit history, i'm looking into how the rpi video pipeline works, and whats missing on the rpi4
19:53anholt_: clever: like video decode? I really won't be able to help there, I had only limited knowledge on the pi3
19:53danvet: clever, yeah, but does userspace ever care?
19:53clever: anholt_: mostly in terms of video output, linux can drive the video output ports on a 3, but not 4
19:54anholt_: oh, display.
19:54clever: danvet: mostly just to tell the user what port something is, so the user can choose the right connector from a dropdown or cfg file
19:54anholt_: you should check out the huge series by maxime ripard on dri-devel
19:54kusma: anholt_: https://anholt.pages.freedesktop.org/mesa/
19:55clever: anholt_: ive already written code that peeks at the state via /dev/mem, and can mostly make sense of the 3&4
19:55clever: anholt_: got a link to the dri-devel stuff?
19:57clever: anholt_: ive also been researching the clock and power domain stuff some, so i can bring the display hw online, without the firmware helping out
19:57anholt_: clever: https://firstname.lastname@example.org/T/ for example
19:58clever: anholt_: ah, thats repeating some info i recently discovered, should be more gold if i keep digging :D
20:05clever: anholt_: do you happen to know anything about power domains and pll control on the rpi3?
20:06anholt_: I've forgotten most of it, all knowledge I had will be found in the clk-bcm2835.c and bcm2835-power.c drivers.
20:06clever: anholt_: clk-bcm2835.c is the one generating the errors, about PLLH (i think) being unable to lock, poking around with bcm2835-power.c hasnt been able to enable the right power domains
20:07anholt_: if you want to extend this stuff to the pi4, you're going to need to do RE.
20:07anholt_: it's not the same.
20:07clever: anholt_: yeah, i have been studying the new bootcode.bin and start4.elf heavily in ghidra
20:07clever: using a combination of ghidra and linux source to make sense of the hw
20:08clever: use linux as the 1st reference, then read /dev/mem and verify if its behaving as expected, and RE to fill in blanks
20:10clever: anoyingly, the bootcode.bin stage is also signed, so its tricky to run custom firmware there
20:17dj-death: MrCooper: the trick of closing exported GEM handles once the last buffer is destroy seems to backfire in chromium
20:18clever: dj-death: oh, that reminds me, i suspect my chromium is leaking gpu resources, ive had problems where a 3d heavy game gets 4 fps and causes ALL 2d rendering to lag, until i restart the GPU process in chrome
20:18clever: dj-death: is there a simple way to query the total GPU ram usage?
20:19clever: i also have a bug where opening the preview window in obs-studio causes my swap usage to rise as a rate of 1gig/minute, and there is no clear cause as to which process is consuming it all
20:21zmike: anholt_: is there anything else I need to do with those piglit patches?
20:21dj-death: clever: hmm not that I know
20:21anholt_: zmike: assign to marge?
20:22zmike: anholt_: I don't think I can?
20:23dj-death: clever: certainly seems to leak file descriptors
20:23anholt_: zmike: ah, thought you had access already
20:23zmike: nope, still learning!
20:23clever: dj-death: i have had problems in the past, where the font loading code would open 2 FD's per font, and it would try to load the same font many times in parallel
20:24clever: dj-death: as a result, resuming too many tabs at once would cause you to go over the ulimit, and the main process gets killed
20:24clever: but that one hasnt happened in many months
20:57clever: can drmModeSetCrtc be used to apply a custom mode to a crtc?
20:57clever: or is that what drmModeAttachMode is for?
21:02imirkin: iirc you have to create a mode object first
21:06clever: imirkin: dont see any function for that step
21:07clever: imirkin: closest i can see is `extern int drmModeAttachMode(int fd, uint32_t connectorId, drmModeModeInfoPtr mode_info);` which feels like it takes a ptr to a mode i allocated myself, such as one on the stack
21:07imirkin: drmModeModeInfoPtr mode_info
21:07imirkin: that's gotta come from somewhere
21:07imirkin: hm, maybe?
21:07clever: imirkin: what if i just put one on the stack, populate it as i feel, and then &mode ?
21:08airlied: that in theory should work
21:08imirkin: how do you use a drm-supplied mode then?
21:08airlied: you get them from the mode list
21:08airlied: and feed it back in
21:08imirkin: oh, and that structure has some ID in it?
21:09clever: drmModeCrtc and drmModeConnector will auto-allocate more drmModeModeInfo's, and populate from the kernel
21:09airlied: imirkin: no it passes back the complete info
21:09imirkin: so that drm knows it's THAT mode?
21:09imirkin: airlied: i see lots of debug prints like [MODE:]
21:09airlied: it never knows it's a specific mode
21:09imirkin: (those prints are from drm core)
21:09imirkin: i figured it was a difference between user-supplied modes vs whatever
21:09airlied: the modes the kernel genertes and the one it consumes are only linked in userspace
21:09airlied: unless atomic has changed things
21:09imirkin: but sounds like just a buggy print of some sort?
21:10imirkin: you're probably right :)
21:10airlied: imirkin: well modes in the kernel have ids
21:10airlied: so EDID probing etc
21:10clever: i'll need to experiment on a few different models of hw, i suspect that the DRM driver on the rpi4 is very lacking
21:10imirkin: airlied: right, but when setting a mode
21:10emersion: atomic hasn't changed things
21:10imirkin: one of the things it prints is what mode is being set
21:10imirkin: and i've seen it just as [MODE:]
21:10emersion: note that there is a USERDEF flag for modes
21:10imirkin: i didn't care enough to actually dig into the code to see what the logic was :)
21:11emersion: imirkin: probably tries to print the mode name
21:11emersion: if you create a custom mode, it'll be empty
21:11clever: in my case, i'm considering abusing DRM and a DPI port for SDR, so i need very specific and custom modes, and pixel clocks to be exact
21:11emersion: (unless you populate the field)
21:11imirkin: emersion: but what defines custom?
21:11imirkin: oh i see
21:11imirkin: so it's whatever you set it to
21:12imirkin: and the kernel pre-pops it with some things
21:12imirkin: but you could totally take one of those modes and put "emersion" into it
21:12emersion: and the kernel would probably just print that
21:13emersion: the kernel populates mode names with just the resolution
21:14imirkin: hm ok
21:29vsyrjala: kernel modes no longer have ids
21:31vsyrjala: and the attachmode ioctl was nuked long ago. all it did before that was allocate kernel memory without actually doing anything else with the mode
21:31vsyrjala: super useful ioctl
21:34airlied: a kmalloc wrapper ftw
22:19robclark: jekstrand: any opinions on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5371 ? I don't think it's waiting for anything else..
22:28jekstrand: robclark: Left you a couple comments on the common bits.
22:28jekstrand: robclark: Nothing complicated
22:42linkmauve: Bummer, my new GPU (someone gave me his RX580) freezes randomly, and even crashes at some point, with an error very similar to this one in dmesg: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3104
22:43imirkin: was the reason someone gave you their RX580 was that it didn't work? :p
22:44jekstrand: robclark: I suppose you'll be wanting me to run it through our CI again? :P
22:44HdkR: Interesting, I don't get anything like that on my RX590, but I also don't really play heavy games with that card :P
22:45imirkin: linkmauve: well, i think you know the drill for reporting bugs / getting stuff fixed...
22:45linkmauve: HdkR, I got it because the Nvidia one was garbage, and the Intel one isn’t really better than my laptop’s.
22:45robclark: jekstrand, depends on how confident you are in that last fixup? Although offhand using `nir_intrinsic_dest_components()` is at least not going to be worse
22:45linkmauve: imirkin, yup. ^^
22:46robclark: (I suspect if it gave a different answer, nir_validate would have already complained
22:49linkmauve: imirkin, this was the original owner’s bug report btw: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1370
22:49jekstrand: robclark: I'll kick it off now
22:49robclark: ok, thx
22:49jekstrand: robclark: Have you pushed with everything?
22:49linkmauve: I’ll have a look at monitoring the temperature, but I have no idea how to measure wattage.
22:49robclark: jekstrand: yeah, that branch is up to date
23:02karolherbst:wished we could do anything to get completly rid of llvm :p
23:02HdkR: sudo apt-get remove clang
23:03karolherbst: yeah... I am not convinced writing a CLC parser is my time well spent :p
23:04karolherbst: airlied: you know what I'd like to do just for the fun of it? making CL in mesa with radeonsi faster than rocm :p
23:05airlied: karolherbst: making it run apps without crashing would be better in some ways than rocm :-P
23:05karolherbst: but I would rather do it for the sake of invalidating "llvm optimizes well against compute workloads" myth...
23:05karolherbst: or well.. we don't know if that's one yet or not actually
23:12anholt_: well that was terrifying. on some branch of hacks, did "git checkout -b origin/master" instead of "git checkout -b new-hacks origin/master" and then git log looked like my old hacks were upstream.
23:31HdkR: karolherbst: I think any compiler stack with sufficient amount of time thrown at it will also optimize all the same idioms. Just depends on duplicating or reusing will get you to optimized state faster :P
23:32airlied: llvm's problem for amdgpu is more the loss of information between the frontend and backend
23:32airlied: reconstructing divergence in the backend isn't as successful as knowing it
23:33airlied: however I'm not sure how big divergence analysis is wrt compute kernels vs graphics shaders
23:35karolherbst: airlied: biggest problem with compute is probably that your input just sucks :p
23:36airlied: yeah or someone porting cpu algorithms and expecting magic :-P
23:49karolherbst: tests/spec/arb_gpu_shader_int64/execution/indirect-array-two-accesses.shader_test is evil :/
23:51imirkin: karolherbst: how so?
23:51karolherbst: uses local mem
23:52imirkin: all local indirect access do (on nvidia)
23:52karolherbst: you don't have to with this shader though :p
23:52karolherbst: or.. mhh
23:52karolherbst: yeah.. I think you should be able to optimize it away
23:54karolherbst: just need to turn the asignment into a function and inline the call :p