00:27 MrBIOS: https://termbin.com/g7m9
00:28 MrBIOS: I've got an old Core2Duo based iMac 5,2 that I'm running Ubuntu 20.04 on, and if I use only efifb, I can get it to run in pure framebuffer mode.
00:29 MrBIOS: I'm getting the message "[drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM" at boot, and that pointed me to https://bugs.freedesktop.org/show_bug.cgi?id=58568
00:29 MrBIOS: however, in my case, I can confirm that I _do_ have PCI quirks enabled
00:42 MrBIOS: anyways, I just filed https://gitlab.freedesktop.org/drm/amd/-/issues/1128
00:43 kisak: not that it helps any, but that's an iMac5,1 (5,2 has intel gma 950 graphics)
00:44 airlied: MrBIOS: did it used to work?
00:45 MrBIOS: yes, it's 5,1 I mis-wrote it here
00:45 MrBIOS: airlied yes, it worked with Ubuntu 16.04
00:45 MrBIOS: I also attached a couple of photos to that bug
00:45 airlied: got a dmesg from the older install?
00:46 MrBIOS: I don't, though I could probably boot up from the USB stick
00:47 MrBIOS: this is RV530, so it's pre-atombios
00:48 MrBIOS: I found radeon_apply_legacy_quirks() which is apparently relevant for that era of driver
00:48 MrBIOS: this seems like an encoding problem, frankly.
00:48 MrBIOS: https://wiki.ubuntu.com/X/Quirks#Monitor_Quirking:__drm_edid.c
00:48 airlied: rv530 has atombios
00:49 airlied: not that matters
00:49 airlied: it's not finding the rom at all
00:49 airlied: MrBIOS: maybe a newer kernel might help, 5.6 or even a 5.7-rc3
00:49 airlied: might be worth a test if you cn find one in a ppa
00:49 MrBIOS: airlied I can try it.
00:54 imirkin: MrBIOS: i saw some recent "fixes" around retrieval of PCI ROMs
00:54 imirkin: perhaps they fixed it a little too well
00:54 MrBIOS: imirkin probably :)
00:54 MrBIOS: 5.7ish, or before?
00:54 imirkin: hold on
00:55 imirkin: hm, i'm not seeing it
00:56 imirkin: perhaps i mixed it up
00:57 imirkin: MrBIOS: commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208
00:58 MrBIOS: hmm, thanks
01:01 imirkin: MrBIOS: looks like that commit was addressing an issue on a MacPro1,1
01:01 MrBIOS: still, similar era
01:01 imirkin: with a 32-bit kernel and lots of RAM
01:01 MrBIOS: a little later.
01:01 MrBIOS: this machine has a mere 2GB of RAM at present, max 4GB supported
01:02 imirkin: depending on the split, anything more than 1GB is "lots" iirc
01:02 imirkin: with > 4GB being oodles :)
01:09 MrBIOS: imirkin I guess I could compile a kernel without CONFIG_HIGHMEM and see if that changes anything
01:10 imirkin: or apply that patch. or revert it.
01:10 MrBIOS: yep
01:10 imirkin: depending on whether you have it or not :)
01:32 MrBIOS: imirkin, airlied , same problem with 5.7-rc3
01:34 airlied: MrBIOS: what kernel was in 16.04?
01:34 airlied: maybe try an 18.04 live cd?
01:34 airlied: see if you can narrow down the ragne it broke in
01:36 imirkin: MrBIOS: is that with or without the patch?
01:37 MrBIOS: presumably with
01:38 imirkin: ok, so did you try without it?
01:38 MrBIOS: imirkin mainline 4.4 LTS
01:39 MrBIOS: not yet
01:39 MrBIOS: kernel 5.7-rc3 dmesg at https://termbin.com/km5f
01:40 MrBIOS: but that's booting with video=efifb:i17
02:06 krh: what's the recommended way to start a pipeline now?
02:06 krh: do I have to wait for the build before I can start the deqp runs?
02:06 krh: oh, looks like no
06:38 tzimmermann: danvet, hi. how can i speed up the merging process for my drm-misc-next PRs?
06:39 tzimmermann: airlied, ^
06:40 tzimmermann: is there anything i can do to improve the PR?
06:44 airlied: tzimmermann: nope I usually only process towards the end of the week
06:44 airlied: if you have an urgent one just ask me in here
06:44 airlied: and I'll try doing it next day
06:45 airlied: tzimmermann: btw cc'ed you on an ast regress
06:46 tzimmermann: airlied, ok, thanks. it's not urgent. the last PR has been waiting for a few days. i was wondering if it got lost or is not good.
06:47 tzimmermann: airlied, ast regression? do you have a pointer?
06:48 tzimmermann: that suspend thing
07:04 MrCooper: krh: trigger the one or two required container jobs; bonus points for cancelling unneeded other jobs that would run automatically after that :)
07:06 MrCooper: danvet: that sounds better, I suppose the sticking point then is how to capture the full state? Whatever the previous master left might not always be desirable
07:12 danvet: MrCooper, yeah hence put it into logind
07:12 danvet: it's already doing the master handover dance for unruly compositors, imo restore working defaults fits in there
07:14 danvet: logind could force a vt switch to itself just to do that
07:14 danvet: and could be wired up with some loginctl fix-my-screens
07:15 emersion: danvet: how do you implement seamless transition from the display manager to the compositor, with a logind fix-my-screens request?
07:17 danvet: emersion, at that point you have random gunk/corruption on your screen
07:17 danvet: not sure how you want to make that seamless
07:17 emersion: my point is: it's not uncommon for display managers to setup properties unsupported by compositors
07:18 danvet: yeah I get that
07:18 danvet: but if you want to support seamless vt switching
07:18 danvet: across compositors with wildly different atomic support
07:18 danvet: then before you vt-switch bake the entire screen down to a single standard plane
07:18 danvet: and disable all the fancy stuff
07:19 danvet: "everyone uses whatever feature they want" and "seamless vt switch" is impossible
07:19 emersion: default property values would fix that, because the compositor could selectively choose to pick the default value (if prop unknown) or not (if prop known)
07:20 danvet: no
07:20 danvet: only way you get fully seamless transition is if the new compositor fully understand what the old one did
07:20 danvet: kernel defaults wont help you with that
07:21 danvet: and for non-seamless "give me something that works" you can just restore
07:21 danvet: and if you don't trust the other guy, logind can do that restoring for you
07:21 emersion: reads like "only way you get seamless transition is hope it works"
07:21 danvet: no where do we need kernel defaults
07:22 danvet: emersion, nope, you need an actual protocol
07:22 emersion: "if it doesn't, you're screwed"
07:22 danvet: which defines what is acceptable and what isn't at handover
07:22 danvet: and who enforces what
07:22 danvet: like logind could check whether the old compositor left a correct simple layout behind for seamless transition
07:23 emersion: i'd prefer a seamless transition if possible, and a fallback to a non-seamless transition otherwise
07:23 danvet: if not, whack it back to defaults from system start-up (or install time or whatever)
07:23 danvet: yeah, you can do all that already in userspace
07:23 landorfini: Mart turned 37 during a vacation, allready old man with piles of experience in technology world, ooh and i have something special, but i would rather use my knowledge to earn something too, once in a life i need to be independent financially!
07:23 danvet: instead we have a "dear kernel, please solve this policy problem for us"
07:23 danvet: and the answer is "nope"
07:24 landorfini: I took a look at opencl , it works absolutely fantasitcally here with ocl gallium bridge.
07:24 emersion: alright, other question: if the default values can't live in the kernel, can they live in libdrm?
07:25 landorfini: i am authoring my first bitcoin miner here, this is actually fun work, because opencl was programmed well by some team matszpk.
07:26 MrCooper: danvet: the kernel has to solve it anyway though for fbcon?
07:26 emersion: that's a good point
07:26 danvet: MrCooper, we do, shittily
07:26 danvet: sometimes
07:26 danvet: essentially about as well as all the compositors
07:26 emersion: plan is to continue to do it this way?
07:27 danvet: well if someone fixes it I'm not going to nack patches ofc
07:27 danvet: but fbcon also doesn't exist always
07:27 danvet: and it might not be what the user wants
07:27 danvet: we have tons of cmdline options for fbcon for the users that do care about their fbcon working like they want it to
07:27 danvet: so I'm not buying the "fbcon is golden" thing
07:28 emersion: fbcon is not golden, but fbcon needs to solve these issues
07:28 danvet: I mean on a modern fedora you're not even going to see fbcon, normally
07:28 danvet: emersion, only for the people who care about fbcon
07:29 MrCooper: that's currently everyone who needs to use a console VT, as first approximation
07:29 danvet: I really think that for a multi compositor system this should be solved in the thing that already handles handover between compositors
07:30 danvet: and that's logind
07:30 danvet: MrCooper, you still have a vt, but as long as you don't go to a non-graphical vt hans just worked to make sure you don't even have fbcon
07:30 danvet: iirc
07:30 danvet: so that there's less thrashing when booting
07:31 MrCooper: I'm talking about actually logging into a console VT
07:31 MrCooper: e.g. to recover from a GUI issue
07:32 danvet: feels a bit much developer hat use-case
07:32 danvet: anyway, if logind folks say they absolutely have to have some defaults that the kernel pulls out of some hat because they can't
07:32 danvet: I'm more on the side of maybe the kernel should do that
07:33 emersion: what about driver-specific props? should logind have a list of *all* props that ever existed?
07:33 danvet: but if this is individual compositors restoring random defaults
07:33 emersion: what about people not using logind?
07:34 danvet: they can invent their own not-logind
07:34 emersion: logind is tied to systemd, so it's really a bad place for putting prop data
07:34 danvet: the thing is, step 1: come up with some protocal among logind and compositors for how this is supposed to work
07:34 danvet: once we have that, we can figure out where the defaults should come from
07:34 danvet: but "where are the defaults from" is step 2
07:34 emersion: a protocol, if any, should only be required for seamless transition
07:35 danvet: and if we do step 2 before step 1 we have a mess
07:35 danvet: emersion, well that's the old dri1 approach of everyone just ignoring the other side, and sometimes it even worked
07:35 danvet: there's a reason logind takes away your drm master if a compositor doesn't obey
07:36 emersion: doesn't obey?
07:38 MrCooper: my take is that DRI1/UMS required cooperation, whereas KMS should allow each entity to ensure correct operation independently from others
07:39 danvet: MrCooper, yeah, but only if you have someone higher up who enforces that
07:39 danvet: which is logind
07:39 danvet: the kernel does _not_ take away drm master rights on vt switch
07:39 danvet: so if you don't have logind, you're already back to dri1 model
07:39 danvet: hence minimally, we need logind people to agree that this restore defaults thing is something they thing is reasonable for their stuff
07:40 danvet: or anything else that has a similar design with something like logind
07:41 danvet:gtg now, ttyl
07:42 danvet: and ofc s/logind/logind or something similar that does the same job/ in the above
07:42 danvet: but I'm not aware of anything else non-systemd
07:43 MrCooper: not getting DRM master is another issue, logind is an established solution for that
07:44 MrCooper: I'm unconvinced it follows logind must manage KMS properties as well
08:22 dj-death: gitlab down?
08:24 tpalli: seems to work, I just pushed to piglit branch
08:25 daniels: dj-death: remove your /etc/hosts override for gitlab.fd.o
08:41 dj-death: daniels: thanks a lot :)
08:41 daniels: np!
09:16 rellla: is there some re-upload of an index buffer done in mesa or in the state_tracker if i want to do glDrawElements with an index buffer of [0,1,2,1000,1001,1002]?
09:17 rellla: this results in a non-indexed draw with 6 draws in lima but should have 1003 draws instead (if there were no optimizations somewhere before)
09:37 daniels: rellla: Lima quite specifically tries to do this for performance reasons
09:39 rellla: daniels: thats why i ask , because i want to implement this 'feature' in lima :)
09:40 rellla: but if i don't miss anything, draw_vbo already comes with an index_size = 0 out of the state_tracker...
09:40 rellla: is it https://elixir.bootlin.com/mesa/mesa-19.2.0-rc1/source/src/gallium/auxiliary/util/u_vbuf.c#L1161 which does that 'magic'?
09:41 rellla: ... didn't in that code in detail...
09:42 rellla: for example: GLuint[0,1,2,3,4,95] results in 96 draws, [0,1,2,3,4,96] ends up with 6 draws
10:07 rellla: ok, found it. it's unroll_indices
10:24 emersion: daniels: is this equivalent to a R-b tag? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4294
10:24 emersion: err, the "This LGTM" comment you made i mean
10:30 daniels: emersion: yeah
10:30 emersion: thx
10:44 pq: danvet, MrCooper, yeah, I understood save&restore as save on start, then restore that every time your KMS state might be lost, e.g. on re-gaining DRM master.
13:11 seanpaul: ramaling_: Can you please review "drm: Fix HDCP failures when SRM fw is missing"?
13:13 ramaling_: sure. I will review today.
13:51 ramaling_: seanpaul: done.
15:03 sravn: tzimmermann: mgag200 work, suprised to see so much work on this driver. Will take a look at the patches later
15:23 imirkin:wonders if removing the cursor to support atomic is putting the cart in front of the horse
15:36 emersion: why do you need to remove the cursor?
15:36 emersion: too much typing? :)
15:37 imirkin: emersion: 4-bit only, no alpha
15:37 mripard: siqueira: thanks for sending a new version :)
15:37 imirkin: so maybe it's actually not that useful
15:38 imirkin: er right, no - no alpha blending, but 1-bit alpha does work
15:38 imirkin: which is most simple cursors anyways
15:38 emersion: eh, i don't know if any compositor supports non-RGBA cursors
15:39 imirkin: it takes an RGBA cursor and converts it
15:39 imirkin: works fine with X, i imagine
15:39 emersion: ah, i see
15:40 emersion: yeah, should be fine then
16:06 tzimmermann: sravn, thanks
16:41 mslusarz: hey, is there a channel dedicated to gitlab.fd.o?
16:44 kisak: #freedesktop maybe?
16:53 daniels: yeah
18:10 robclark: hmm, why are panfrost jobs in the pipeline for https://gitlab.freedesktop.org/robclark/mesa/pipelines/139900 ? That shouldn't have any panfrost patches which aren't in master..
18:11 robclark: maybe because my master was behind? Could that confuse CI into thinking that there were panfrost changes as well?
18:14 anholt: do you touch any meson.build?
18:19 robclark: hmm, yeah, freedreno specific ones..
18:19 anholt: any meson.build can have global impacts, so everything gets retested
18:21 robclark: actually, it does seem to be because my master was behind.. when I pushed that forward, it no longer thinks panfrost is part of the change..
18:22 robclark: (there do still seem to be some radv jobs, although I think they aren't running if I just trigger arm_build + arm_test)
18:23 anholt: hmm. maybe the match doesn't work like I thought, and that's concerning.
18:26 robclark: current behavior (modulo the gotcha that it is comparing to base in one's personal gitlab tree rather than the upstream) seems fine for manually triggered pre-marge pipelines.. maybe not for marge pipelines tho..
18:34 dj-death: anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4594 looks good with the couple of defines?
18:35 anholt: yeah
18:39 dj-death: thanks
18:42 anholt: thanks for working on this!
19:24 anholt:wants to just get off of using these shared arm runners if we can't get reliable artifacts uploads from them.
19:28 robclark: anholt: does this look like actual fail or CI issue (other than apparently a few UnexpectedPass)? https://gitlab.freedesktop.org/robclark/mesa/-/jobs/2502525
19:32 anholt: dunno, the a530 gles3 runs look slow too (was like 5 min when I merged, I thought.
19:34 anholt: but the deqp says it had only been going for 2:20
19:34 anholt: so unless the board just stopped reporting silently, maybe it was a CI fail?
19:37 robclark: ok, i'm going to assume it was.. the only diff btwn that and earlier runs where that job passed were some a6xx specific fixes
19:39 anholt: austriancoder: how's the x86 baremetal container going? any chance we could clean up and merge that part soon?
20:32 hakzsam: eric_engestrom: did you branch. or is it delayed?
20:34 eric_engestrom: a bit of both: I cut the branch (see staging/20.1 on the upstream repo) but I wanted to run it through the Intel CI and I'm having issues with that, and then I got distracted :]
20:35 eric_engestrom: I can easily pick a newer commit for the 20.1 branch if you want to get something that just landed in
20:35 hakzsam: no, just wondering why there is no tag for the new branchpoint
20:37 hakzsam: is this expected?
20:42 eric_engestrom: there will be one, I'm just being slow :]
20:43 karolherbst: the day is not even over and people already complain? :O
20:51 eric_engestrom: karolherbst: kids nowadays, huh?
21:08 dj-death: anholt`: where is $ARTIFACTSDIR/${driver}-shader-db.txt pulled from?
21:09 kisak: it's nice to see marge wasn't swamped today
21:13 jekstrand: marge is so much faster now that we're not running every HW on every MR
21:18 bnieuwenhuizen: or is it because we currently have 0 runtime tests for our HW in the CI? :P
21:19 kisak: always having runners ready immediately helps too (from the disabled pre-pre-merge pass)
21:20 jekstrand: Yeah, that helps too
21:41 hakzsam: eric_engestrom: np, I'm just asking, not complaining at all :)
21:50 eric_engestrom: hakzsam: hah I know, I'm just kidding :P
21:51 eric_engestrom: btw the tag has been pushed, but I'm battling our broken scripts to get actual release out :]