00:30anarsoul: yuq825: hi
00:30anarsoul: oops, wrong channel
01:49Lyude: mdnavare: oops-I responded to your message from earlier but forgot to highlight you. It's a little late now but did you still need help with the topic branch stuff (maybe sometime tommorroe if it's too late?)
01:50mdnavare: Lyude: no worries actually danvet askeed me to have the drm maintainer do it so i have pinged mlankhosrt abt it
07:08MrCooper: Cogitri: looks like broken apps/middleware not handling 10 bits per component configs correctly; the i965 driver disabled those by default (allow_rgb10_configs=false), but iris doesn't
07:26Cogitri: I'll try that in a bit, thanks
07:41rellla: anholt: i had some issues with my before/after scripts.
07:44rellla: i manually executed eglretrace and have the following output: https://pastebin.com/raw/ySvFccJH
07:45rellla: --pgpu mentions that GL_ARB_timer_query and GL_EXT_timer_query are missing
07:45rellla: --loop=1 leads to a segfault, omitting both works
07:46rellla: please ignore the many env and the mesa debug output ...
07:47rellla: this is with lima driver on Mali450. can i fix or workaround that?
07:49HdkR: Kind of need timer queries if you want to profile GPU time :P
08:04rellla: HdkR: yeah, seems i have to add query support to lima first :p
08:14MrCooper: Cogitri: to be clear, if allow_rgb10_configs=false avoids the problem, it's not a Mesa issue
08:24Cogitri: Yes, but would it be acceptable to set this on a distro level to work around this for now?
08:38MrCooper: it would be better to fix the bugs instead
08:40Cogitri: Well yes, but I don't think we have the manpower to fix bugs in XWayland or Chromium/SDL
08:41MrCooper: this isn't an Xwayland issue either
08:41MrCooper: quite possibly not SDL either
08:43MrCooper: the problems with just disabling 10 bpc configs by default are: a) it breaks use-cases where 10 bpc configs are actually needed b) it removes pressure to actually fix the bugs
08:44Cogitri: Well yes, but I think users don't have a lot of appreciation to not have that fix for b) because it breaks their setups
08:46Cogitri: And I think about all of ours users use 8bpc, so everyone who needs that setting a in their driconfig is better than breaking the setup of like 99.9% of our users, I suppose
08:46Cogitri: I mean the situation sucks either way, but disabling 10bpc for now is the best workaround AFAICS
08:47Cogitri: Also, if the bug is in neither Xorg nor SDL, were would it be then?
08:49ickle: SHM pixmap bites again
08:50MrCooper: Cogitri: the app/middleware using SDL
08:50MrCooper: I guess it could be SDL itself, not sure how its API handles this offhand
08:51Cogitri: I guess it's SDL, since this seems to happen for all SDL apps
08:51MrCooper: SDL 2 and/or 1.2?
08:52Cogitri: Not sure about 1.2
08:52Cogitri: It also happens in Chromium though (but fixed itself in QtWebEngine 5.14, it was broken in 5.12) so there's that
08:54MrCooper: not seeing it with all SDL 2 apps though (with the radeonsi driver)
08:54Cogitri: I tried with the ones that are mentioned in the Alpine bug report
08:58MrCooper: not seeing it with `mpv --vo=sdl` e.g.
09:01MrCooper: nor minetest
09:41danvet: MrCooper, are there some quick microbrenchmarks for copy engine performance on amdgpu?
09:41danvet: because curiosity
09:41MrCooper: "copy engine" as in SDMA?
09:42danvet: not necessarily
09:42danvet: just the fastest gpu engine to move stuff from system memory to vram and back
09:47MrCooper: running any GL app with AMD_TEST=testdmaperf runs various transfer benchmarks
09:59danvet: MrCooper, AMD_DEBUG found it, thx very much
09:59MrCooper: np, "old" radeonsi driver then :)
10:00danvet: hm yeah might be on an old mesa
10:07danvet: MrCooper, hm do you have any tests for non-snooped vs snooped GTT?
10:08bnieuwenhuizen: if it isn't in testdmaperf we have nothing built-in
10:14MrCooper: yeah not that I know of, but shouldn't be hard to add to testdmaperf or the kernel driver's benchmark
11:18dormito: I've not been able to find much solid info online: anyone know what the state of displayport MST (multi-stream transport) is (in linux, obviously)?
11:24daniels: dormito: it works
11:25dormito: for all cards (that have hw support, obviously)?
11:25daniels: it depends on the driver. which driver did you have in mind?
11:25dormito: radeon (and to be clear I don't mean amdgpu)
11:26dormito: I have a displayport hub, but couldn't get MST to work correct, but that was like 3 or 4 years ago. Never ended up looking into it much.
11:27daniels: yes, pre-amdgpu radeon has MST support
11:30dormito: nice. thanks. I'll have to find my hub again then :)
11:32shadeslayer: dormito: it entirely also depends on the hardware though, I've tried MST chaining, but could only drive the displays at 4K30Hz since the hub inside the monitor didn't support anything more than that
11:33dormito: shadeslayer: I have an independant hub (don't think that should make much diff..). IIRC the problem I kept running into (years ago) was that I couldn't unmirror my displays
11:34shadeslayer: ah, yeah that definitely worked last I checked ( on radeon and intel )
11:35dormito: lol. I don't have any intel i915's with the DP lines brought out (just hdmi, or vga)
12:28danvet: tzimmermann, do you plan to land your generic_fbdev_setup series soon?
12:28danvet: I'd like to rebase mine next week latest so I can start merging stuff
12:28danvet: but it's going to conflict a lot with yours
12:29tzimmermann: danvet, i can. i'll merge it into drm-misc-next later today. does this work for you?
12:29danvet: should I hope
12:52mlankhorst_: free pull request out for dp phy compliance :)
12:55MrCooper: dormito: actually beware that radeon's MST support has never gotten out of experimental state, needs to be enabled via a module parameter
13:11sravn: danvet: I do not get this lifetime stuff somehow
13:11sravn: struct device is not the same as struct drm_device
13:12sravn: And we have drmm_ stuff for resources that are tied to the lifetime of a drm_device
13:13sravn: But we allocate the overall struct, that contains struct drm_device, using devm_. This is confusing.
13:13sravn: If out struct drm_device tied to struct device, implied by devm_ allocation, or is it the ligefime of struct drm_device, implied by drmm_?
13:15dormito: MrCooper: good to know (that probably would have taken me a while to realize :/)
13:16imirkin: mirrored displays = not actually MST
13:17imirkin: and will result in seeing a single connector on the GPU
13:17imirkin: the SST stream is just replicated to all the sinks
13:18sravn: danvet: What I imply in the above rant is also that devm_drm_dev_init() is misnamed. As the example states in drm_drv.c we cannot use devm_kzalloc() due to the lifetime issues, yet it uses the devm_ suffix that imply the same lifetime as when using devm_kzalloc()
13:37shadeslayer: Hi! Could someone add me a as a member of Mesa so that I can attach the right tags to my MR's?
13:46danvet: sravn, not all of devm_ is bad
13:46danvet: just devm_kzalloc
13:46danvet: devm_iomap is fine, as are all the others
13:47danvet: so not really agreeing the misnaming ...
13:54bnieuwenhuizen: shadeslayer: I don't think we give people commit access just for that if you don't have a history of good commits yet
13:54shadeslayer: bnieuwenhuizen: Does the ability to tag MR's absolutely require commit access?
13:55shadeslayer: I presumed I could be a member, have access to tag things, but not commit them
13:55emersion: (this is GitLab's "reporter" role)
13:56emersion: (so allows closing arbitrary issues)
13:59bnieuwenhuizen: I think the problem with reporter is that you can delete labels from a proejct as well
13:59bnieuwenhuizen: al labeling a MR is Developer, not reporter (unlike labelling an issue)
14:02emersion: ah, indeed
14:19shadeslayer: ah darn
14:42sravn: danvet: This really do not help my confusion - sorry. If we take vbox as an example. What is the lifetime of vbox (allocated using devm_drm_dev_alloc())?
14:43sravn: danvet: vbox contains a drm_device - so lifetime is tide to drm_device - OK?
14:43danvet: sravn, yup
14:43danvet: managed with drm_dev_get/put()
14:44sravn: danvet: and not the lifetime of the struct device inside drm_device
14:46sravn: danvet: And we handle lifetime of drm_devive using a kref - behind the drm_dev_get()/put()
14:47sravn: danvet: kref is not the same as devres. Some we have out our managment of the lifetime of drm_device - and it is not handled by devres - OK?
15:00danvet: sravn, sry lots of mtgs
15:11tzimmermann: danvet, pushed now
15:14danvet: sravn, ok got some time now hopefully
15:14danvet: sravn, maybe easier to first understand what's actually going on
15:15danvet: so we have devm_drm_dev_alloc -> devm_drm_dev_init() -> devm_add_action()
15:15danvet: and the devres action we're adding is _not_ a kfree, or a call to drm_dev_release() or anything like that
15:15danvet: but a call to drm_dev_put()
15:15danvet: it's in devm_drm_dev_init_release
15:16danvet: sravn, so I guess first step is: is this all clear to you what's going on here, and why this works with devres, despite that devres is the wrong thing for drm_device lifetime?
15:24danvet: sravn, maybe one on top: devm_drm_dev_init predates my drmm_ stuff by one year
15:24danvet: so this devm_ stuff doesn't really have anything directly to do with drmm_
15:27sravn: danvet: starts to make sense again, will take a fresh look at it later tonight. Garden duties right now... If it makes sense then, I will reply on the list
15:31danvet: sravn, I think there's definitely room for improvement in the docs
15:31danvet: it's a bit much magic
15:31danvet: but I think there's other cases where the devres release action doesn't directly release, but only drops the refcount by 1
15:31danvet: which might or might not release the underlying resource for real
15:39danvet: tzimmermann, hm I guess another step would be to remove the 2nd parameter of drm_fbdev_generic_setup
15:39danvet: and make sure drivers set dev->mode_config.preferred_bpp correctly in all cases where it's not 32 bpp
16:04ajax: MrCooper: it's early but !4432 looks like it's having quite the impact
16:09MrCooper: yeah :) I was actually expecting it to take a while for all active MRs to rebase on top of it
16:22danvet: tzimmermann, just finished the rebase, just one simple conflict so I think went all smoothly
16:31emersion: > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
16:31emersion: pull in arbitrary other resources, including CRTCs
16:31emersion: danvet: will the CRTC just be removed?
16:32emersion: with a uevent?
16:32emersion: (from user-space PoV)
16:34danvet: emersion, removed, what do you mean?
16:35emersion: drmGetResources stops returning it
16:35danvet: pull in
16:35danvet: here means pull into the atomic commit
16:35emersion: how can user-space figure out it's taken? atomic test-only?
16:35danvet: i.e. for a while that crtc will be busy with a commit
16:35danvet: and return EBUSY
16:36danvet: it's not taken out anywhere at all
16:36danvet: aside from the EBUSY the only other thing you observe is that vblanks are stuck for a while
16:36danvet: and then come back
16:36emersion: i see
16:37danvet: at least the only thing I've heard is the spurious EBUSY reports from a few compositors
16:37danvet: and it's papered over by just repeating the pageflip until it goes through
16:37emersion: yeah, we do this in wlroots
16:37danvet: but I don't think all compositors do this
16:37emersion: i think weston doesn't
16:37danvet: hence the hack
16:38danvet: which won't stop us from eventually (or never) adding a real api
16:38danvet: emersion, hm cynism?
16:38emersion: thanks for the explanation, i mean :)
16:38danvet: ah ok, sounded a bit like "thanks weston"
16:39danvet: all the hack should result is convert crashing compositors into stuck compositors
16:39danvet: like the ones that already do the "wtf EBUSY, let's retry for a bit" hack
16:39emersion: sorry, should've been less vague
16:39danvet: anyway if you feel like, r-b/ack on the patch appreciated
17:14sravn: danvet: Guido ask about whats needed to get "drm/bridge: Add NWL MIPI DSI host controller support" applied.
17:14sravn: IMO ready to go in
17:15sravn: It is bridge/ - so not an area I usually touches...
17:21danvet: sravn, check with some bridge people here, then push
17:24sravn: narmstrong: OK to apply "drm/bridge: Add NWL MIPI DSI host controller support" to drm-misc-next? This and the binding are IMO ready
17:26sravn: pinchartl: ^^
17:27pinchartl: sravn: -ENOTIME, so if you think they're ready, go for it :-)
17:27pinchartl: having a quick look
17:28pinchartl: for the DT bindings
17:28pinchartl: port 0 is defined as
17:28pinchartl: + Input port node to receive pixel data from the
17:28pinchartl: + display controller. Exactly one endpoint must be
17:28pinchartl: + specified.
17:28pinchartl: then there's two endpoints, I assume this means that only one should be specified
17:29pinchartl: but that seems to model a software policy
17:29pinchartl: I think both should be specified
17:29pinchartl: or maybe even routed to two different input ports actually, if the mux is inside the bridge
17:29pinchartl: could you have a look and tell me what you think ?
17:30pinchartl: I'm about to start a meeting though
17:30sravn: pinchartl: I do not recall if this was asked before. Will you type a Q on the ML?
17:30sravn: pinchartl: OK, I will follow-up on ML
17:30pinchartl: I can ask on the ML, but after my meeting
17:33sravn: pinchartl: Mail sent...
18:05pa: question about the llvmpipe driver: how to query the capabilities? or where to see those? f.ex. does it support anisotropic diffusion?
18:06pa: sorry, anisotropic filtering
18:18imirkin: pa: glxinfo
18:18imirkin: look for the ansi ext
18:18imirkin: (iirc no)
18:18imirkin: aniso ext*
18:19pa: imirkin, glxinfo gives me info about some opengl v 1.4 driver, and the intel hwaccelerated driver
18:19pa: i can't see the llvm one
18:19imirkin: (in your env)
18:22pa: okay thanks
18:22pa: let me retry
18:23pa: right, so it seems no anisotropic filtering
18:24imirkin: and by default, llvmpipe texture filtering is non-conformant
18:25pa: not sure what that means, let me google
18:25imirkin: (for higher perf)
18:25imirkin: well, texture() is fairly well defined as to what it's supposed to do
18:26imirkin: for various interpolation settings
18:26imirkin: llvmpipe doesn't do that correctly :)
18:26pa: ah in that sense
18:26pa: i see
18:26imirkin: there are ways to tell it to do the conformant thing, but (surprise surprise) it's slower
18:27imirkin: and it doesn't matter in practice
18:27pa: but anisotropic filtering does a lot of difference in some scenarios
18:27imirkin: it's also completely undefined
18:51jekstrand: Is Joshua Ashton or IRC?
18:56HdkR: I don't believe I've seen him on IRC
18:57HdkR: But maybe I've missed his alias
19:26airlied: pq: feel free to write aniso support :-), it would get gL4.6 enabled for llvmpipe
19:27imirkin: probably meant for pa? --^
19:27airlied: pa: ^ :-)
19:27imirkin: but pq should feel free to do so as well :)
19:27ajax: it's not hard, just slow and pointless.
19:27airlied:isn't at all sure what sw aniso impl would look like
19:28airlied: ajax: welcome to sw GL :-P
19:28airlied: GL 4.6 specifies 16.0 aniso as the minimum maximum
19:29imirkin: but doesn't specify what that means, right?
19:29imirkin: or is there an actual definition now?
19:29airlied: well there is at least one CTS test
19:29airlied: "without specifying a
19:29airlied: particular formulation of anisotropic filtering."
19:31airlied: oh it has a sample idea
19:32ajax: the cts test looks pretty light on details, just queries and error conditions and "drawing something correctly does not error"
19:33airlied: wierd I wonder how I failed it
19:33ajax: hmm, i take it back
19:34ajax: it does verify your own output against itself for successively higher anisotropy levels
19:34ajax: and demands that some rough pattern look successively smoother
19:37airlied: yeah no GL 4.6 for now :-P
19:37ajax: but i mean... i thought the sample algorithm wasn't much more than scaling the bilinear inputs according to dx/dxy
19:38ajax:stops reading something he has no intention of implementing
19:38airlied:only has about 10 cts tests failing for gl4.5
22:49pinchartl: seanpaul: ping