01:23 airlied: yay found my first bug in cts for my gl4.5 attempt :P
01:34 bl4ckb0ne: is `vertex.instance` supported in glsl?
01:38 bl4ckb0ne: seems not, NV_vertex_program4 is not implemented
06:27 hakzsam: dcbaker: looks good, thanks!
06:27 hakzsam: jekstrand: great, I will run pipeline-db on my side :)
08:54 airlied:assumes cts runnger shouldn't be taking 9GB and I've got a memory leak
09:50 austriancoder: does anybody use driver_rbug and got
09:50 austriancoder: rbug-gui building
10:50 MrCooper: karolherbst: have they fixed their connection?
10:51 karolherbst: MrCooper: sometimes they can't do anything about it
10:51 karolherbst: I am against blocking people with bad connections, period
10:52 karolherbst: we are not living in a world where everybody has a perfect connection and I see no reason blocking somebody for it if there are other ways to get rid of annoying messages
10:52 MrCooper: I'm not going to disable join/leave messages for one person
10:52 karolherbst: then get a proper client which allows you to disable it from one person?
10:52 karolherbst: it is solveable on a technical level
10:53 karolherbst: my client allows me to ignore hide/joins for inactive persons eg
10:53 MrCooper: is it possible with hexchat? Not going to switch client for one person either :)
10:54 karolherbst: I don't use hexchat, but that seems to be one of the clients missing such features from what I've heard
10:54 karolherbst: but somebody could also write patches for hexchat to add those
10:54 karolherbst: ...
10:54 karolherbst: but given that nobody cares for so long...
10:55 karolherbst: anyway, I don't see why it would be a problem to add a feature like "ignore hide parts for constantly rejoining persons"
10:55 karolherbst: would make the life better for everyone
10:55 MrCooper: anyway, gotta go, bbl
12:07 MrCooper: karolherbst: IMHO a better solution would be for them to use something like an IRC bouncer; otherwise they'll likely miss some things said on the channel anyway
12:18 karolherbst: yeah, probably
12:19 karolherbst: but that also means paying for some server
12:20 karolherbst: I think I am more upset about the fact that apparently "banning" is the "best" solution here as I already see dozens of other ways on how something like this can be handled... but maybe that's just me
12:22 karolherbst: it's also discriminating against those not being able to afford servers for bouncers or better internet connections at home, but that's more of a side effect
12:47 MrCooper: karolherbst: anyway, when was the last time they tried? I can't seem to find the ban, maybe someone removed it
12:48 karolherbst: dave removed it
12:48 karolherbst: but I think they tried yesterday or so
12:48 tomeu: eric_engestrom: do I need to do something else so this MR is considered for stable? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4462
14:04 mareko: danvet: what do you need nowc for?
14:37 danvet: mareko, oh just wanted to see what happens without that in the testdmaperf numbers
14:38 jekstrand: hakzsam: Ugh... My bad. Stupid copy+paste error. I'll post a new version in a few minuts. Sorry for the false alarm. :-(
14:48 hakzsam: jekstrand: no worries
14:52 jekstrand: hakzsam: Just force-pushed the MR. This version should work.
14:52 jekstrand: hakzsam: No fossil-db changes on my side.
14:52 hakzsam: I will check that
16:48 hakzsam: jekstrand: pipeline-db looks fine now, thanks :)
16:48 jekstrand: \o/
16:48 jekstrand: hakzsam: How are things looking with the CFG rework?
16:49 hakzsam: got distracted by something else, I'm sorry. Can you wait a bit more? :/
16:49 jekstrand: Yeah
16:49 hakzsam: thanks, I will let you know
17:46 arora: /quit Goodnight!
18:54 anholt_: so, something changed recently and I've been flooded with messages about failed marge-bot-generated pipelines like the ones found in https://gitlab.freedesktop.org/chema/mesa/pipelines and https://gitlab.freedesktop.org/hakzsam/mesa/pipelines (look for yaml invalid)
18:54 anholt_: the commits involved don't seem to include any .gitlab-ci changes
19:23 mdnavare: danvet: hwentlan: Can the drm_object_property_get_value() be called from within the kernel if i have to access the property value?
19:26 mdnavare: Lyude: vsyrjala: In general if i have to get the atomic property value in the kernel, is it possible to use the get_property drm helpers or thats only for the userspace to call?
19:58 danvet: mdnavare, from within the kernel you shouldn't need to go through this
19:58 danvet: but instead go through the state structure directly
19:58 danvet: (with right locks depending where you are and all that)
19:58 danvet: there's some exceptions, but they're very special
19:59 mdnavare: danvet: within the kernel i set the connector->vrr_capable_property
20:00 mdnavare: now in debugfs i need to get the value of this property
20:00 danvet: mdnavare, nah not that
20:00 danvet: for atomic properties there's nothing there, it gets decoded into state structure
20:00 danvet: somewhere in drm core code
20:00 danvet:not going to fire up an editor now to find that stuff
20:00 danvet: but looking for all users of vrr_capable_property should find it
20:02 danvet: mdnavare, ok I succumbed and looked, this isn't an atomic property
20:02 danvet: but an immutable one
20:02 danvet: for immutable ones you need to go some get_value thing
20:02 mdnavare: danvet: yes I set this using drm_connector_set_vrr_capable_property
20:03 mdnavare: danvet: which calls drm_object_property_set_value
20:03 mdnavare: danvet: so my question was from kernel can i call drm_object_property_get_value() ?
20:05 mdnavare: danvet: or is it not allowed to be called from within the kernel?
20:06 danvet: hm I did add a comment that this is uncool
20:06 mdnavare: danvet: I dont see this being called anywhere else in the kernel , one thing is that since the kernel is setting this property i could just call that internal helper to get the value of that instead of going to drm to get it
20:07 danvet: yeah generally we just go to the internal thing
20:07 danvet: properties are for the uapi
20:07 danvet: also publishing the exact same thing that's available as a property is a bit silly in debugfs
20:08 mdnavare: danvet: mainly for IGT and general debug
20:08 danvet: yeah but igt can just look at the uapi property
20:08 mdnavare: danvet: but yea agreed that probably unnecessary
20:08 danvet: and for general state dumping we have stuff like drm_state_info() (not sure that's wired up for i915, should definitely do that)
20:09 danvet: oh it's auto-wired, I forgot
20:09 danvet: mdnavare, if you want maybe add it there or so
20:10 mdnavare: danvet: okay cool will take a look