14:01 tagr: imirkin_: pong
14:02 imirkin: tagr: can you have a look at the email i sent about the patch to rework gem creation?
14:03 tagr: imirkin: I sent you a couple of thought about that yesterday
14:03 tagr: you may have missed them, let me find the IRC logs
14:03 imirkin: i see them. i didn't until now.
14:04 imirkin: the test case is "start X" :)
14:05 imirkin: took me a real long time to track that one down :p
14:05 imirkin: tagr: the problem is the size passed to the gem creation thing
14:05 imirkin: it has a BUG_ON(size & (PAGE_SIZE - 1))
14:06 imirkin: tagr: the path is nouveau_gem_new -> drm_gem_object_init -> boom
14:06 imirkin: because the fixup runs after gem_object_init now
14:08 tagr: huh... interesting...
14:10 tagr: imirkin: okay, let me type up a patch
14:11 imirkin: thanks. i meant to over the weekend, but then things happened.
14:11 imirkin: i discovered it when testing danvet's gem reservation something-or-other patches
14:12 tagr: imirkin: yeah, I'm not sure if I was the only one who ran into the original breakage, and it sure did take a while for you to run into this
14:13 tagr: so I wonder if maybe this is rare (if starting X triggers it I guess it isn't) or very few people actually test Nouveau on linux-next
14:13 imirkin: s/on linux-next//
14:13 tagr: =)
14:14 imirkin: i almost never do
14:14 imirkin: except when actively required
14:14 imirkin: (such as was the case here)
14:14 imirkin: ben rebases on drm-next every so often, but i don't think he has yet
14:14 imirkin: this should be possible to hit with GL too, i think
14:14 imirkin: but definitely with the ddx
14:15 tagr: imirkin: I'm kind of hoping after I get my current work in progress sent out to enable and fix Nouveau on more Tegras, that we can get at least some basic testing enabled in our nightly testing
14:15 imirkin: +1! :)
14:16 kherbst: 👍
14:16 tagr: imirkin: looks like it would actually be really easy to trigger by just running some barebone libdrm_nouveau based test that allocate a very small nouveau_bo
14:16 imirkin: even a really big one
14:16 imirkin: just not page-size-aligned
14:16 tagr: yeah
14:16 tagr: probably not worth a separate test-case, though
14:17 kherbst: tagr: by any chance, you didn't have any chance to look deeper into the recent GLX/EGL regression?
14:17 kherbst:hopes somebody else takes care of this
14:18 kherbst: ufff
14:18 karolherbst: silly IRC client
14:19 tagr: kherbst: one of the things I plan to look at once I'm through with the kernel patches
14:19 karolherbst: ahh cool :)
14:19 tagr: I first need to get Nouveau to work on more boards, otherwise I have to go switch boards all the time, and I hate that
14:20 karolherbst: hehe
14:20 imirkin: tagr: if you have trouble repro'ing yourself btw, i can probably test tonight
14:20 karolherbst: I was asked today about issues with the xavier board, then I noticed it's volta and I lost interest :p
14:20 imirkin: although like you said, it should just be a call to nouveau_bo_new with an unfortunate size, and nothing else.
14:20 karolherbst: tagr: are you working on adding support for the xavier to nouveau as well or is that for later?
14:21 tagr: imirkin: I should be able to manage, just need to get my userspace into a sane state, been switching between too many branches lately, so things explode all the time because of missing symbols in one of the dependencies
14:21 tagr: imirkin: I'll let you know if I can't reproduce
14:21 imirkin: kk, thanks for have a look!
14:22 tagr: karolherbst: yeah, I've actually got WIP patches to enable the GPU on Xavier, but I haven't gotten further than getting it to probe without falling over
14:22 karolherbst: makes sense
14:22 karolherbst: we also don't have the firmware...
14:22 tagr: karolherbst: turns out there's quite a few things that we need to program in addition, though most should be only of concern to Tegra (because no VRAM)
14:23 karolherbst: yeah, makes sense
14:23 tagr: I've got firmware for the gv11b, but I haven't been able to load it, that secboot2 code makes me dizzy
14:23 karolherbst: tagr: wait then, skeggsb reworks most of it anyway :D
14:23 imirkin: don't worry, skeggsb is rewriting it.
14:23 tagr: oh, good
14:24 karolherbst: my gp107 in my laptop still doesn't work :)
14:24 imirkin: you think it's confusing now ... you just wait! :p
14:24 karolherbst: but I have a workaround
14:24 tagr: skeggsb: let me know if you need me to look at it, I'd be happy to see if I can make gv11b work on top of that
14:24 karolherbst: https://github.com/karolherbst/nouveau/commit/7e24d8aba04726dde912434420ba2f8a962a6dab :)
14:24 tagr: karolherbst: does the gp107 firmware not work for you?
14:24 karolherbst: nope
14:24 karolherbst: I need that workaround
14:25 karolherbst: don't ask, I don't know more
14:25 karolherbst: no idea how I even figured that out
14:25 imirkin: if it works for linksys routers...
14:25 karolherbst: must have been a super wild guess
14:25 karolherbst: :)
14:25 tagr: 0x200 is that PMU register that's used to turn engines on and off, right?
14:25 imirkin: yes
14:25 karolherbst: yep
14:25 karolherbst: the sleeps are in there to make it work across runpm cycles
14:25 imirkin: i think "MC" is what that part is called, not PMU
14:26 karolherbst: yeah
14:26 tagr: oh right, yeah, MC
14:26 tagr: I was wondering if eventually we want to be smarter about what exactly we enable and when
14:26 tagr: probably not worth it just yet, though
14:26 imirkin: we already try to be
14:26 imirkin: or you mean like runpm style?
14:26 karolherbst: volta/turing needs it
14:26 tagr: for Tegra we seem to just write all ones to that register (and that other one for the SLCG (?))
14:26 karolherbst: my turing GPU consumes 1W in idle....
14:27 karolherbst: it's one of those big ones
14:27 karolherbst: those 300W big ones
14:27 karolherbst: or maybe the power sensor is just bonkers
14:27 tagr: nice... perhaps I should look at whether we actually need that all-ones write on Tegra at all, then
14:27 tagr: might be leftover from way back when
14:28 imirkin: you may need to turn on some things that nouveau doesn't normally touch
14:28 imirkin: but each engine (nvkm/engine) in its init has a thing of like which MC bits should be flipped
14:28 tagr: imirkin: yeah, maybe, but everything?
14:28 karolherbst: like the power gating stuff
14:28 imirkin: tagr: "it doesn't work, let's flip everything on"
14:28 imirkin: "it works!"
14:28 karolherbst: tagr: we don't even enable power gating by default :p
14:28 tagr: ship it!
14:29 imirkin: it was already shipping ... provide a firmware update!
14:30 tagr: heh... I'm not going to comment on that one, I'd just sound like a broken record
14:30 karolherbst: the entire secboot situation is just stupid
14:30 karolherbst: and I hope the situation will change drastically in the near future :p
14:32 tagr: yeah, it's very frustrating
14:33 karolherbst: I still don't see "good" reasons for adding it. The bad ones I know of are to save crappy business models and not standing up against the content industry
14:34 karolherbst: ohh, fixing driver bugs without having to ship a new driver is also a good one, but luckily nvidia doesn't do that (yet)
14:35 karolherbst: "uff.. our driver is like 500MB big, it would be nice if we could just ship the firmware, they are soooo small" :p and I am sure that's a dicussion somebody already had within nvidia
14:35 imirkin: tagr: i thought it was some anti-counterfeiting measure
14:36 karolherbst: imirkin: for that you only need to sign the vbios, no?
14:37 imirkin: yea dunno
14:38 tagr: I don't know much about the exact reasons, it's probably all of them
14:39 karolherbst: yeah.. I just wished there would be a good one
14:41 tagr: well, I'm sure someone thought the reasons were good
14:41 karolherbst: I think the most frustrating part here is, that we have to deal with something which no apparent benefit for anybody
14:41 tagr: either way, it is what it is and I don't think it's going to change
14:41 karolherbst: probably not
14:41 tagr: so we just have to make the best of it
14:41 tagr: where "best" includes actually providing firmware that people can use
14:42 karolherbst: ohh, you know, there could always keays appear out of nowhere into the internet :p
14:51 meeku_: afternoon all
14:51 meeku_: does anyone know what is actually going on in this register?
14:51 meeku_: #define NV_PDISP_RG_STATUS(i) (0x00616314+(i)*2048) /* R--4A */
14:54 tagr: ugh... so now gp10b is broken again... I don't believe it
14:55 karolherbst: fun...
14:55 tagr: [ 33.526074] nouveau 17000000.gpu: bus: MMIO read of 00000000 FAULT at 418198 [ IBUS ]
14:56 tagr: this used to work just a couple of days ago...
14:56 karolherbst: uhmm
14:56 karolherbst: that's a GPC_BROADCAST reg
14:57 meeku_: I'm trying to find something that I can poll to detect a vsync... I thought that register had promise
14:58 meeku_: it seems to have some counter which is incrementing at 60hz
14:58 meeku_: but i don't think it increments at vblank
14:58 meeku_: i'm guessing its the unstall count
14:59 meeku_: and RG in the name being resource generator or something ? perhaps indicative of some internal gpu buffer allocation/flip for the current frame
14:59 tagr: meeku_: I think RG is actually the raster generator
14:59 imirkin_: tagr: still holding out hope for maxwell firmware...
14:59 meeku_: well in that case RG would make even more sense
14:59 meeku_: the register has flags for hsync/hblank/vsync/vblank
15:00 meeku_: and ovbiously the register exists (*i*2048) per head.. i've checked them all
15:00 meeku_: and i don't see any of the those flags being set
15:05 meeku_: assuming we have an int handler for gpu events, there must be some register checked to see if we have a vblank/hblank condition etc
15:06 meeku_: i guess we don't use horizontal syncs that muc h these days..at least i haven't since the days of emulating Amiga copper on pc to wait for raster lines etc..
15:06 meeku_: but the vsync/blank is pretty important
15:19 imirkin_: meeku_: drivers/gpu/drm/nouveau/nvkm/engine/disp/headgf119.c
15:19 imirkin_: and drivers/gpu/drm/nouveau/nvkm/engine/disp/headnv50.c::nv50_head_rgpos
15:21 imirkin_: meeku_: https://github.com/envytools/envytools/blob/master/rnndb/display/g80_pdisplay.xml#L127
15:21 imirkin_: which appears at 0x616000 + 0x800*head
15:22 imirkin_: dunno about that +0x314 reg
16:03 meeku_: GF119 = 0x6100c0+(id*0x800), test bit 1
16:03 meeku_: G80 = 0x616000 + (id*0x800) + 0x340 (use bits 16-31 as vblank count)
16:03 meeku_: NV50 = 0x61002c + (id<<4 bit)
16:03 meeku_: So those would be the 3 different places to check
16:04 imirkin_: G80 = NV50
16:05 imirkin_: so something's off in your logic somewhere :)
16:08 meeku_: https://www.irccloud.com/pastebin/OoQuXvnd/
16:08 imirkin_: right...
16:09 imirkin_: vblank_get is to enable vblanks
16:09 imirkin_: (vblank_put is to disable them. i hate that semaphore nomenclature...)
16:09 meeku_: ahhh ok, that makes no sense
16:09 meeku_: :)
16:09 meeku_: get/put ok with you now
16:09 meeku_: so we want rgpos
16:09 imirkin_: that gives you the vblank position
16:12 meeku_: and for gf119 there isn't an equivalent ?
16:12 imirkin_: gf119_head = {
16:12 imirkin_: .state = gf119_head_state,
16:12 imirkin_: .rgpos = nv50_head_rgpos,
16:13 imirkin_: didn't go anywhere... if it ain't broken, and all that
16:36 meeku_: amazing, something that didn't move between revisions :)
16:36 meeku_: ok, time to grab some food then give this a test
16:37 meeku_: one step closer to a really slick LFB :) Of course at some point I guess I need to work out which head is active, i could probably use that previous RG register to see which has counts incrementing
16:37 meeku_: no count, no head
16:42 tagr: karolherbst, imirkin_: when you guys run tests, do you run with CONFIG_DEBUG_MUTEXES=y?
16:45 tagr: I see this:
16:45 tagr: [ 113.105867] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
16:45 tagr: [ 113.105973] WARNING: CPU: 3 PID: 3328 at kernel/locking/mutex.c:1415 mutex_trylock+0x11c/0x160
16:45 tagr: that's from drm_gem_close_ioctl()
16:46 imirkin_: tagr: highly unlikely.
16:46 imirkin_: [that i run with that]
16:47 imirkin_: i definitely don't run with lockdep
16:48 tagr: I don't think it's caused by any of my local changes, but I can't really test that because I don't even get to that point without the local changes...
16:48 tagr: doesn't seem altogether harmless, though
16:51 imirkin_: tagr: do you know what that message is indicative of?
16:52 tagr: imirkin_: I suspect it might point to a use-after-free
16:52 imirkin_:is surprised ... no
16:53 tagr: that ->magic is supposed to just point at the lock itself, sort of as a way of checking that when it's getting used, things are still as expected
16:53 tagr: I'm trying to add some more debugging output to find out more
16:54 imirkin_: i rarely delve into the kernel
16:54 tagr: imirkin_: I can repro the BUG_ON() and my fix seems to... well... fix it
16:54 imirkin_: and outside of my little adventure over the weekend, i've barely looked at gem/ttm
16:54 imirkin_: yay
16:54 imirkin_: i assume the fix is "get rid of the BUG_ON"? :)
16:58 tagr: imirkin_: heh =) I'll send it out shortly
16:58 imirkin_: or the proper fix ... build with CONFIG_BUG=n
16:59 imirkin_: that solves a whole slew of issues
16:59 tagr: it'd be great if you could test it with "start X", for some reason my setups are rebellious today, can't seem to get anything working beyond allocating a BO
16:59 imirkin_: well, it won't hit on tegra anyways
16:59 imirkin_: i'll try to give it a whirl tonight
17:00 imirkin_: perhaps you can get your employer to sponsor some desktop hw for you too :)
17:00 imirkin_: i know it's expensive, but ...
17:01 tagr: yeah, I've been thinking that I should perhaps get some desktop hardware to test on
17:01 tagr: I'd rather not use my workstation for testing, I've had some bad experiences with that in the past =)
17:02 tagr: actually, I do have a Jetson Xavier which does have a PCIe x16 (which is actually x8 I think) so I could probably use that
17:02 tagr: linux-next does have PCI support for that
17:02 tagr: Jetson Xavier, that is
17:03 imirkin_: separate box is highly preferable
17:03 imirkin_: i'm constrained by space, sadly
17:03 imirkin_: so i test on my main desktop
17:03 imirkin_: with 3 GPUs plugged in :)
17:03 imirkin_: which is also why i tend to avoid kernel work and hang debugging
17:05 tagr: understandably
17:05 tagr: I recall one instance where I was trying to quickly check a patch on a workstation, ended up with a corrupted git tree somehow
17:08 imirkin_: yeah, i try to be careful when booting drm-next kernels
17:09 imirkin_: i don't mount my "big" filesystem
17:09 tagr: in retrospect I should've just booted with the rootfs mounted read-only
17:09 imirkin_: anyways, desktop nvidia GPU on arm is an adventure
17:09 tagr: I was arrogant, so I deserved it
17:09 imirkin_: can probably be made to work
17:09 imirkin_: but there's various cache coherency items
17:09 imirkin_: x86 is pretty forgiving
17:10 tagr: so lock->magic is NULL in the failing case, which means it's gone through mutex_destroy() before it's getting unlocked
17:16 imirkin_: not precisely this, but there IS a persistent issue which hits everyone except ben
17:16 imirkin_: it's gem-related, but that's all i remember
17:17 imirkin_: some kind of WARN trace-back, which he claims is impossible, although with a use-after-free it's probably more achievable
17:17 tagr: imirkin_: do you have a bugzilla or something for it?
17:18 imirkin_: karolherbst might remember
17:18 imirkin_: and/or have it in his dmesg
17:18 karolherbst: ufff, yeah
17:18 karolherbst: didn't see it for a while now though
17:18 imirkin_: it's not like SUPER common, but it does happen with some regularity
17:19 karolherbst: sometimes it happened like 100 times a day
17:19 karolherbst: and then there is weeks of silence
17:21 imirkin_: come to think of it, i don't know that i've seen it in a bit either
17:21 imirkin_: despite no kernel changes
17:22 imirkin_: must be a phase of the moon thing
17:22 imirkin_: or perhaps seasonal - that's why ben didn't see it when we were seeing it - his seasons are all backwards, so now he should be seeing tons of them? :)
17:22 tagr: I wonder if the moon phase explains why everything's breaking for me today
17:23 tagr: can't run a simple kmscube anymore
17:23 karolherbst: probably
17:23 imirkin_: tagr: was kmscube adjusted for your situation?
17:23 imirkin_: i.e. separate display + render?
17:23 tagr: imirkin_: yeah, we deal with that in Mesa nowadays
17:23 imirkin_: oh, right, there's a tegra_dri or whatever?
17:24 tagr: exactly
17:24 imirkin_: kk
17:24 imirkin_: and woe be unto whoever bundles the same display controller with multiple gpus?
17:24 tagr: as karolherbst reported it regressed for X, but kmscube should work fine
17:25 karolherbst: yeah, kmscube worked for me
17:25 karolherbst: well
17:25 karolherbst: on the tty
17:25 karolherbst: but yeah
17:25 tagr: it actually did work fine just a couple of days ago and I don't I have any kernel changes that would cause it to break
17:25 tagr: hmm... I may have rebased Mesa at some point, but doesn't sound like that would cause IBUS FAULT errors
17:26 karolherbst: tagr: I didn't test for a while though
17:26 karolherbst: maybe something broke it
17:26 karolherbst: who knows
17:26 tagr: ugh... I hate it when that happens
17:26 karolherbst: well, that's why I want to wire up the jetson nano to the gitlab CI
17:26 karolherbst: but that's pointless with broken EGL/GLX :)
17:27 tagr: so I've been working on these patches for about a week now, going from one SoC to the other, trying to fix things up and then when I go back and want to check one last time everything is broken again
17:27 tagr: I probably was stupid and rebased Mesa at some point in between and probably only updated one of my root filesystems, so I didn't notice the breakage right away
17:28 tagr: ugh... how am I supposed to track this down now?!
17:28 tagr: perhaps some digging through git reflog
18:01 tagr: interesting... seems like dma_resv_fini() is destroying a lock (using ww_mutex_destroy()) that ttm_bo_put() wants to acquire using mutex_try_lock()
18:15 imirkin_: tagr: danvet has some patches
18:15 imirkin_: which address things which sound a lot like the things you're talking about
18:15 imirkin_: in fact i was testing them when i discovered the gem_new unpleasantness
18:16 imirkin_: (which i naturally blamed on him first, but after some more careful analysis, we arrived at the conclusion that they had nothing to do with it)
18:17 tagr: I'll go look
18:19 imirkin_: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
18:20 imirkin_: tagr: https://patchwork.freedesktop.org/series/65577/
18:22 tagr: imirkin_: that sounds similar indeed
18:23 tagr: but I think the two are still orthogonal
18:23 imirkin_: the nouveau change is unrelated to your thing
18:23 imirkin_: but the stuff he's doing to ttm seems relevant maybe
18:23 tagr: what I'm seeing seems to be an ordering issue between drm_gem_object_release() and ttb_bo_put()
18:23 tagr: ttm_bo_put() even
18:23 imirkin_: ah ok
18:37 tagr: imirkin_: drm_gem_object_release() destroys the drm_resv object's mutex and ttm_bo_put() tries to lock it, so that doesn't work
18:37 tagr: not sure we can move things around much without a big rework, though
18:37 tagr: seems somewhat brittle
18:38 imirkin_: ouch :(
18:38 imirkin_: while i comprehend the issue, i can offer no suggestions on resolving it
18:39 tagr: for example, I don't know why nouveau_bo_del_ttm() checks nvbo->bo.base.filp
18:39 imirkin_: my understanding of GEM and TTM tend to be at high levels only
18:39 tagr: that seems like it's unnecessary, but it also looks like the only reason why we call drm_gem_object_release() before ttm_bo_put() (because drm_gem_object_release() needs that filp to tear it down)
18:40 tagr: hmm... trial and error it is
19:56 imirkin_: tagr: btw, did you have a patch for me to test? or are you trying to fix the ordering bits?
20:23 meeku_: so that vsync detect works! :)
20:23 meeku_: but as is the way.. with every step comes more questions
20:23 meeku_: lol
20:24 meeku_: on this particular machine, a laptop with gt 650m
20:24 meeku_: if it boots up using the laptop display, the native resolution is 1920x1080, the image is edge-to-edge and i "assume" it is head0, because the head0 register works for vsync
20:24 meeku_: all perfect
20:25 meeku_: if I plug in an external hdmi monitor, also 1920x1080 and switch to that.. GOP still works, detects 1920x1080.. but the screen is not edge to edge, it looks like the scaler has squished it into the middle.. some sort of dodgy edid timing perhaps ?
20:25 meeku_: also, the vsync then needs me to use head1
20:26 meeku_: with the slightly squished image, waiting for the vline to be say >= 1075 means it's missing the vblank and you can see a fixed tear line at the top of visible image
20:27 meeku_: so 1) is there a way to determine which head is active ?
20:27 meeku_: 2) I'm guessing fixing the squished image would probably require a full mode-setting
20:30 imirkin_: meeku_: look at nvkm/engine/disp intr stuff
20:31 imirkin_: there's a hw scaler which can be used to take a framebuffer of one size and show it on a screen of a diff size
20:31 imirkin_: it could be that the scaler is actually active on the internal screen
20:31 imirkin_: but not active on the external one
20:31 imirkin_: since the GOP always generates a fixed 640x480 or whatever size framebuffer
20:31 meeku_: its on given the mode is 1920x1080 and the monitor native res is the same
20:31 meeku_: odd
20:32 imirkin_: ok, but the *framebuffer* size may be diff than the mode
20:33 meeku_: it's giving me back 1920x1080 with a 1920 pitch when i set that mode via GOP, so I'm assuming the fb is right, otherwise i'd be overwritting other mem, the whole boot sequence/bios etc is also squished on the external screen
20:33 meeku_: until you get into Windows obviously and the driver kicks in
20:36 imirkin_: hm ok.
21:00 meeku_: ok, so register .. 0x022448 seems to give total head count
21:00 meeku_: (7)
21:02 imirkin_: capability
21:03 meeku_: then there is mask from 0x612004 & 0x0000000f
21:04 meeku_: and i guess I'm wanting INTR_HEAD_STATUS
21:06 meeku_: 0x610a74 ?
21:32 imirkin_: meeku_: so basically all kepler+ gpu's can have 4 yeads
21:32 imirkin_: heads*
21:34 meeku_: ok, makes sense
21:34 meeku_: so in the gop world / pre proper driver.. only one display is active at a time
21:54 imirkin_: tagr: thanks for the patch. will try to try tonight :)
22:11 meeku_: ok, so based on gf119_head_state(struct nvkm_head *head, struct nvkm_head_state *state)
22:12 meeku_: i've got h/vtotal's sync start/end per head
22:12 meeku_: and i have values for 0 and 1
22:12 meeku_: 0 being the laptop screen, 1 the external
23:03 meeku_: tried 3 different monitors now.. they all seemed to be squished.. so i doubt it's edid now, must be the gpu underscanning
23:07 imirkin_: 3 identical monitors? :p
23:10 meeku_: no, 3 totally different make/model.. to rule out edid
23:10 meeku_: :)
23:10 meeku_: hannsg, samsung and aoc
23:10 meeku_: so it must be the gt650m gpu doing the squishing
23:10 meeku_: i even tried a different hdmi cable
23:12 meeku_: so annoying, with a massive black border around the display, quality all messed up and it messes up the vsync too
23:13 meeku_: this is starting to feel like a lost cause :)
23:13 imirkin_: do you contorl the modesetting code?
23:14 meeku_: I can do, my original aim was to rely on GOP to get the mode and then do all these other tweaks to make it work "nicely", so I setup the Write Combining, PCI/e options, the link speed thing we looked at a while back.. + vsync.. so for pure 2D non accelerated stuff it would have been great
23:14 meeku_: but it seems like going the full fb+modesetting driver route may be the only option
23:15 imirkin_: on the bright side, you shoudl be able to fairly directly lift all the nouveau code
23:15 meeku_: that is a very bright side
23:15 imirkin_: very little of it is linux-dependent
23:15 imirkin_: everything in "nvkm" is pretty portable
23:16 imirkin_: everythign outside is the glue that ties it to drm
23:16 meeku_: i guess my biggest challenge is really understanding the structure of what is there, and a lot of the nomenclature
23:16 imirkin_: yes
23:16 imirkin_: it's a lot
23:16 meeku_: like IOR, SOR.. (guessed output route ?)
23:17 meeku_: it seems like there is a hell of a lot of auxillary cruft one needs to know to simply fire up a monitor
23:18 meeku_: i2c, edid, parse edid.. get mode values.. plls, clocks.. timing tables.. framebuffer, crtc, dac etc...
23:18 meeku_: this crap used to be like 20 lines of asm in the 90s and even less on Amiga :)
23:19 meeku_: somewhere the world went mad
23:20 imirkin_: welllll
23:20 imirkin_: option rom always had it
23:20 imirkin_: it installed the int10h handler
23:20 meeku_: when i used to set modex/unchained modes.. and all that sort of stuff.. for weird modes like 360x480 on vga
23:21 imirkin_: there was no DP-MST in the 90's :p
23:21 imirkin_: or 10bpc YUV 4:2:0 encoding
23:21 meeku_: yeah..
23:21 imirkin_: this shit got complex over the past 10y or so
23:22 meeku_: over complex imho
23:22 imirkin_: dp-over-thunderbolt-over-usbc -- too complicated?
23:22 meeku_: lol
23:22 imirkin_: no? then just add a DP hub to the mix
23:22 meeku_: with a backup carrier pidgeon
23:23 RSpliet: wasn't the 90s the time you needed a high end GPU for anything other than 1024x768 or 800x600?
23:23 imirkin_: i had a s3 virge
23:23 imirkin_: handled 1152x864 just fine
23:23 imirkin_: (and later, 1600x1200... that trinitron was *nice*)
23:24 meeku_: i miss my cirrus logic VLB svga
23:24 meeku_: :)
23:24 RSpliet: humblebrag... that must've had at least 16MiB of RAM
23:24 imirkin_: heh. vlb.
23:24 RSpliet: back when it was still called 16MB
23:24 imirkin_: fun to remember crazy old things
23:24 HdkR: imirkin_: What's the encoding scheme for 16bpc? :)
23:25 imirkin_: like the sound cards which came with IDE controllers on them
23:25 imirkin_: so you could plug the cdrom drive into them
23:25 imirkin_: or ESDI ...
23:25 imirkin_: HdkR: same as 10bpc?
23:25 imirkin_: but with more c per b?
23:25 RSpliet: pretty sure my soundcard had a firewire port... and my dad's had a joystick connector
23:25 imirkin_: or more b per c...
23:25 HdkR: Ah, so still 420 then
23:25 imirkin_: HdkR: the 420 has nothign to do with the 10bpc afaik
23:25 Lyude: skeggsb: poke, btw, did you see what I said about the issues with bumping the encoder limit for DRM and maybe trying to see if we can get nouveau to use less encoders?
23:25 RSpliet: 420 does make you see interesting colours...
23:26 imirkin_: it's just that 10bpc = more bits. more bits need more bandwidth. and bandwidth is finite.
23:26 imirkin_: unlike memory and cpu power, which are infinite
23:26 HdkR: Just didn't know if you could fit 16bit in to 422 or 444 :)
23:27 HdkR: Over HDMI 2.0
23:27 imirkin_: 640x480...
23:27 imirkin_: works fine
23:27 HdkR: lol
23:27 imirkin_: that's what i mean tho
23:27 imirkin_: if you want like 4k@60@16bpp, something's gotta give
23:27 Lyude: I remember the experiment from the other day not working, but I think that's just because we need to just rearrange things a bit so maybe we just create fake encoders and have sors/piors/dacs (maybe?)/fake mst encoders all implemented through separate drm_bridges that handle acquiring the resources from nvkm
23:27 imirkin_: er, bpc
23:29 Lyude: just from what I've read through so far of nouveau's modesetting code it doesn't seem like it would be impossible
23:30 meeku_: right.. well time for me to call it a day, the fight shall be resumed tomorrow :)
23:30 Lyude: we'd probably be able to end up with one drm_encoder per head that way, which seems to match a bit closer to reality with how nv hardware does things (from what I can tell)
23:42 meeku_: night