02:19 scientes: I have a pretty nice video card, but it isn't work anything when it locks up every few hours. Is there a card I can get that won't do that?
02:19 scientes: 01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 770] (rev a1)
02:20 scientes: also, is there a list of card that have UEFI firmware so it will work on arm64?
02:21 scientes: Intel doesn't sell discrete GPUs
02:21 scientes: and amdgpu doesn't support multi-monitors
02:24 karolherbst: scientes: what do you mean by amdgpu doesn't support multi monitors?
02:24 karolherbst: I once setup a system with 4 displays connected over DP with an AMD gpu
02:24 scientes: oh
02:24 scientes: the cheap-ass one I got needs to be primary vga and doesn't seem to support two
02:25 karolherbst: strange
02:25 karolherbst: maybe ask inside #radeon about that?
02:25 imirkin: scientes: amd gpu's support up to 6, i believe, depending on the specific board.
02:26 scientes: they are also more expensive, but yeah i'll look at buying another amdgpu
02:28 rhyskidd: ccccccglbjjgfffucunkckgjrvugnkjjklhftctgehif
02:28 karolherbst: ahh, those remaining CTS bugs....
02:28 karolherbst: rhyskidd: that's exactly how I feel about the CTS right now
02:28 rhyskidd: sorry ...
02:28 rhyskidd: :)
02:28 rhyskidd: summed it up well, didn't i
02:28 karolherbst: the cts runner is doing like several iterations over the tests
02:28 karolherbst: and if I do one iteration, I basically get 0 fails
02:28 karolherbst: but at some point, tests start to randomly fail
02:28 karolherbst: and even later, it just aborts
02:29 imirkin: scientes: on the bright side, they work well
02:30 karolherbst: we really should get our threading issues fixed :/ at least skeggsb had a plan to do it while also doing the memory rework for vulkan, so we just take care of both things at the same time
02:31 imirkin: he's got his hands full
02:31 karolherbst: well, he told me he will work on it next
02:31 imirkin: i just want the mechanism to make explicit VA placements
02:31 imirkin: yeah, he said that about a year ago too.
02:31 imirkin: shifting priorities at work, etc. hard to predict.
02:31 karolherbst: right
02:33 karolherbst: imirkin: I think he wanted to mainly prototype some vulkan stuff to figure out what would be the required API or something like that
02:33 karolherbst: apperantly he already got something
02:33 imirkin: yeah
02:33 karolherbst: but I never saw any of it
02:33 imirkin: me neither.
02:33 karolherbst: which... is a little frustrating
02:33 imirkin: but i'm sure it'll get dumped at some point in a mega-series
02:34 karolherbst: the kernel bits? yeah, maybe
02:34 karolherbst: well most likely
02:43 rhyskidd: imirkin: are you okay if i put your gp108 traces in nvidia_bios repo?
02:43 imirkin: sure
02:44 rhyskidd: is your strap_peek 00400080?
02:45 imirkin: what reg is it again? 101000?
02:46 imirkin: 00400080
02:46 rhyskidd: yup, thks
02:48 imirkin: looks like nvbios needs improvement - https://hastebin.com/ikuhuyucum.makefile
02:48 imirkin: i didn't see anything complain in the nouveau executor
02:49 karolherbst: imirkin: because it is ran on signed firmware
02:49 karolherbst: check the FALCON table
02:49 karolherbst: there are several images inside the VBIOS
02:49 karolherbst: and the DEVINIT one is executing those
02:50 karolherbst: we have no public documetnation on those methods sadly
02:50 imirkin: it's in the first subroutine called by the first init script
02:50 karolherbst: right
02:50 imirkin: are those not called by us?
02:50 karolherbst: not
02:50 karolherbst: *no
02:50 karolherbst: all on the PMU
02:50 imirkin: 0x00007fd4: 75 0b CONDITION 0x0b
02:50 karolherbst: check the gp100 devinit implementation
02:51 imirkin: 0x00004a36: 0c 24 02 00 01 00 00 00 00 00 00 00 [0x0b] R[0x02240c] & 0x00000001 == 0x00000000
02:51 imirkin: hm. which is true for me.
02:51 imirkin: didn't realize the pmu would execute the vbios now...
02:51 karolherbst: well
02:52 karolherbst: it does now
02:52 karolherbst: you have a falcon table with like 4 or 5 images
02:52 karolherbst: each with a code+data section
02:52 karolherbst: in theory we could just disassemble those with nvbios
02:52 imirkin: yeah. just haven't been tracking those changes.
02:53 karolherbst: I mean, the devinit script parser should be actually inside the vbios
02:53 karolherbst: sooo we could just read the code to figure out what those unknown opcodes are
02:53 imirkin: right.
02:53 imirkin: that's how we did it originally.
02:53 karolherbst: thing is, those devinit scripts touch secured registers afaik
02:53 rhyskidd: nvbios supports reading the falcon table since changes i made earlier this year or so
02:53 imirkin: ah =/
02:54 karolherbst: rhyskidd: adding envydis support would be nice :D
02:54 imirkin: https://hastebin.com/toqixihiwi.coffeescript
02:54 imirkin: i get a *ton* of errors
02:54 rhyskidd: i know :D
02:54 imirkin: including failure to parse the falcon tables
02:54 karolherbst: imirkin: used nvagetbios?
02:54 karolherbst: won't work anymore
02:54 imirkin: no
02:54 imirkin: vbios.rom. always.
02:55 karolherbst: mhhh
02:55 imirkin: never used nvagetbios
02:55 karolherbst: weird
02:55 karolherbst: that should work
02:55 imirkin: oh. no strap = major fail.
02:55 karolherbst: ohh, really?
02:56 karolherbst: I didn't add mine and the gp107 vbios is parsed kind of okayish
02:56 imirkin: hm no. fail either way.
02:56 karolherbst: maybe gp108 is special, or yours is?
02:56 karolherbst: nouveau is fine with it though I figure?
02:57 rhyskidd: the other gp108 vbios we have also fails in similar ways
02:57 karolherbst: ahh, crap
02:57 karolherbst: the thing is, the vbios is kind of split into several parts
02:58 rhyskidd: https://hastebin.com/qatamenuyi.rb
02:58 karolherbst: and since pascal they kind of started to make excessive use of it
02:58 karolherbst: nvbios doesn't handle it
02:58 imirkin: well, this one's plugged in if you want me to get anything
02:58 karolherbst: normally nouveau threw everything out we didn't need so it was one part again but maybe....
02:59 karolherbst: well I more or less know what the issue is I think
02:59 karolherbst: never looked into those gp108 ones though
02:59 karolherbst: maybe I should?
02:59 karolherbst: _odd_
02:59 imirkin: has anyone traced blob evo method calls?
03:00 karolherbst: skeggsb I think
03:00 imirkin: [other than skeggsb, who i assume isn't around]
03:00 karolherbst: rhyskidd: I can parse it...
03:00 imirkin: karolherbst: now type 'q'
03:00 karolherbst: ohh wait, I see those issues
03:00 rhyskidd: yeh, it is parseable -- just a few oob reads and seemingly reporting issues
03:01 karolherbst: yeah... let me check something
03:01 karolherbst: right...
03:01 karolherbst: why isn't nouveau fixing that
03:03 karolherbst: the thing is, each part has a weirdo checksum section with equal size
03:03 rhyskidd: ok, so pulling from nvidia_bios will include imirkin's gp108 vbios and mmiotrace now
03:03 karolherbst: which basically just needs to be cut out
03:08 rhyskidd: imirkin: my gp107 vbios has almost exactly the same seq subroutine with the missing opcodes https://hastebin.com/dunidafeme.makefile
03:09 rhyskidd: it's changed only by the value written to R[0x021804]
03:19 karolherbst: oh heh
03:19 karolherbst: oh wow, thats messy, right
03:20 karolherbst: okay, things are a bit different with those vbios
03:24 karolherbst: we basically just need to parse the parts of the vbios correctly
03:24 karolherbst: "BIOS part 1 at 0xec00 size 0x10800" is not exactly right
03:24 karolherbst: as the second part starts at 0x1f400 not 0xec00
03:26 karolherbst: and then we need to fix the table offsets
03:26 karolherbst: kind of
03:26 karolherbst: "requested OOB u8 at 0x1fc64" -> should read from 0x30464
03:27 karolherbst: uhm, no, wait
03:27 karolherbst: the pointer is actually correct
03:28 karolherbst: anyway, two valid regions: [0x0, 0xec00) and [0x1f400, 0x2fc00)
03:29 karolherbst: imirkin, rhyskidd: I didn't know it was that broken for gp108 as I thought reading the vbios.rom from nouveau still works
03:29 karolherbst: I guess I may just fix it for real inside nvbios then
05:06 Riastradh: OK, I confirmed that writes to VRAM via the 0x700000 aperture are reflected by reads from a bo mapped into CPU address space from VRAM, and vice versa!
05:07 Riastradh: ...which unfortunatey means the problem is somewhere else.
05:07 Riastradh: Worked on first try, too, amazingly.
12:13 karolherbst: pendingchaos: maybe you have some ideas. with your patch to add support for compute shader invocations counter, after a few iterations the test testing it gets stuck with a "fifo: fault 00 [READ] at 00000000027f0000 engine 00 [GR] client 1d [GPC0/T1_7] reason 02 [PTE] on channel 2 [00ffbb0000 cts-runner[7180]]"
12:13 karolherbst: with a trap handler it would be so easy to debug that :(
12:14 karolherbst: or maybe...
12:14 karolherbst: imirkin: the shader isn't dead until we kill the channel or whatever, right?
12:14 karolherbst: or is it already dead and that's why we have to kill the channel?
12:15 karolherbst: I am currently wondering if the shader just waits until the kernel has decided what to do?
12:16 karolherbst: mhh, I need to check my cuda-gdb mmiotrace
12:18 pendingchaos: karolherbst: this one https://github.com/karolherbst/mesa/commit/6799747d6d5c405484fda56aa2abb7e709ec163c ?
12:18 pendingchaos: I don't have any ideas though
12:19 karolherbst: yes
12:20 karolherbst: mhh, next time I should attach a gdb and verify it is the indirect path
12:31 karolherbst: mhhh, yeah, at least I see some stuff inside the mmiotrace
12:31 karolherbst: but also quite a lot of those "UNKNOWN 278653.534457 5824 0xd0174000 f3,a4,c3 0x0 0"
13:49 imirkin: anyone around with a GM20x+ GPU that has DP and/or HDMI ports? if so, i'd be curious to see the "DRM: DCB ..." lines
13:49 imirkin: [from dmesg]
13:56 imirkin: hmmm nevermind. the DCB docs say the field's only applicable to DP. even though it's set for my HDMI ports... hrm (the bandwidth max)
14:04 karolherbst: imirkin: any idea why we might get a read fault when (or before) calling nvc0_hw_get_query_result?
14:05 imirkin: yeah
14:05 imirkin: that stuff is pretty tricksy
14:05 imirkin: basically hw_get_query_result doesn't add a use for the buffer it uses
14:06 karolherbst: wierd thing is, it only seems to happen at the 5th iteration of the cts :(
14:06 imirkin: because that could cause a kick theoretically
14:06 karolherbst: mhh
14:06 imirkin: so it's the caller's job to do this AND make sure there's enough room for all the commands that hw_get_query_result would add onto the pushbuf
14:06 karolherbst: oh, I see
14:06 imirkin: also ... iirc there's a file which #define's something which makes the auto-kick stuff not happen
14:06 imirkin: so you have to explicitly call PUSH_SPACE ahead of time
14:07 imirkin: it'd be at the very top, before the #include's
14:12 karolherbst: imirkin: btw, do you know if skeggsb also wanted to implement explicit fencing while doing the memory stuff?
14:13 imirkin: seems likely
14:13 imirkin: he wants to do everything all at once :)
14:15 karolherbst: :)
14:50 karolherbst: imirkin: interesting, so the CTS test is 1. starting the query 2. binding a buffer through glBindBuffer(GL_QUERY_BUFFER, qo_bo_id) 3. do a draw 4. end the query and then read out the result through glBindBuffer(GL_QUERY_BUFFER, 0);
14:50 karolherbst: (and as the next step, read it out via glBindBuffer(GL_QUERY_BUFFER, qo_bo_id)
14:54 imirkin: skeggsb: ok, so logically speaking, there MUST be hardware controls for at least scrambling, but most likely the tmds clock divider as well
14:54 imirkin: skeggsb: that's because scrambling can be turned on even for the low frequencies
14:55 imirkin: skeggsb: i don't see anything in the EVO class docs about any of this stuff, so i surmise that it's one of the unknown bits in the hdmi control thing
14:55 imirkin: going to be making more traces where i flip between high and low modes
15:36 rhyskidd: karolherbst: (re: vbios offsets) that probably explains why the few volta bios report a bunch of offset errors too
15:37 karolherbst: yeah
15:46 imirkin: skeggsb: ok, located in the gv100 public docs
15:47 imirkin: (which is nice, since a bunch of stuff moved around on gv100 it seems, but not this)
15:50 rhyskidd: yup, three voltas + the gp108 vbios's: https://paste.fedoraproject.org/paste/eZhl2Z72jG-kolpUNH0KSA
15:51 rhyskidd: karholherbst: ^ i wont have a chance to work on fixing that this weekend, but might be useful to you
16:25 karolherbst: imirkin, rhyskidd: https://gist.github.com/karolherbst/a4413d2da13942b92d2846f571908dee
16:25 karolherbst: I am not sure when to actually enable that weird offseting though
16:25 karolherbst: but with that I am able to read imirkins gp108 vbios
16:28 karolherbst: the techpowerup vbios need special fixing anyway
16:28 karolherbst: nouveau does more or less the same
16:29 karolherbst: I just need to take a deeper look on the condition when to do that
16:46 Mac101: Hi, anyone know if 4k 10bit hevc hardware decoding is supported with nouveau? card is a 1030 & looking to get the aids that is nvidia proprietary drivers off my system :>
16:47 imirkin: Mac101: it is not.
16:47 imirkin: best bet is to get an amd gpu.
16:47 imirkin: or intel.
16:51 Mac101: ah ok
16:51 Mac101:opens an rma
17:28 imirkin: karolherbst: do you have any GM20x mmiotraces which have any hdmi in them available?
17:28 karolherbst: I don't
17:29 imirkin: even just a port with nothing plugged in is likely enough
17:30 karolherbst: still. didn't do much on that gm204
17:30 imirkin: k
17:30 karolherbst: I could probably do a trace if it would help you though
17:30 imirkin: hold on, i'm updating the nvidia_vbios repo
17:31 imirkin: maybe some new traces in there
17:33 imirkin: aha! Lyude to the rescue.
17:34 imirkin: hmmmm
17:37 imirkin: skeggsb: i'm seeing blob write to 690300+x instead of 690000+x on GM20x.
17:38 imirkin: which is weird since it's back to 690000 on GP10x
17:38 imirkin: or could be that it's just different data being written in
17:44 karolherbst: Riastradh: maybe the responsible engine is just not enabled?
17:45 karolherbst: imirkin: do we have docs on those regs? probably not
17:45 Riastradh: karolherbst: How could I test that, or where should it be enabled?
17:46 imirkin: karolherbst: not extremely. just going off the gv100 thing.
17:46 imirkin: and what nouveau does.
17:46 karolherbst: Riastradh: 0x200 I think should tell you
17:47 karolherbst: bit 29 is PDISPLAY
17:47 karolherbst: but maybe something else needs to be enabled as well
17:47 Riastradh: mmio register 0x200?
17:47 karolherbst: yeah
17:47 Riastradh: Where does it normally get set?
17:47 karolherbst: I highly doubt that it is something tirival as that
17:47 karolherbst: but who knows
17:47 karolherbst: Riastradh: no idea, somewhere when enabling the engines?
17:48 imirkin: Riastradh: mc is responsible for enabling engines
17:48 Riastradh: nvkm/subdev/mc/nouveau_nvkm_subdev_mc_nv50.c: nvkm_wr32(device, 0x000200, 0xffffffff); /* everything on */
17:48 Riastradh: Like that?
17:48 karolherbst: ahh yeah
17:48 imirkin: yes, like that.
17:48 karolherbst: nvkm_mc_enable
17:48 imirkin: but i don't think we enable EVERYTHING do we?
17:49 karolherbst: I doubt it
17:49 Riastradh: Well I didn't touch that line!
17:49 Riastradh: Same line in 4.4.
17:49 Riastradh: Same line in Linus's master as of a month or so ago.
17:49 karolherbst: I mean, I have no idea how to tell if the evo is up or not
17:50 karolherbst: but it sounds like that something with evo itself is weird
17:50 karolherbst: maybe do an engine reset before all that display enabling stuff
17:50 Riastradh: How do I do an engine reset?
17:50 karolherbst: maybe there is something else wrong
17:50 karolherbst: maybe it was a bug and got fixed
17:50 karolherbst: nvkm_mc_reset + engine magic
17:52 karolherbst: anyway, maybe different appraoch
17:52 karolherbst: what do we know?
17:52 karolherbst: we don't see any replies from evo on the host
17:53 karolherbst: so that's either because evo doesn't read the same buffer as we write stuff to or because evo doesn't run or we don't see when evo wrties stuff or maybe some other reasons. Which is kind of a stupid situation as I have no idea how to debug that further other than to guarentee we can read vram
17:54 Riastradh: I've confirmed that I can write to VRAM via the 0x700000 mmio window, and read back via CPU mappings, and vice versa.
17:54 karolherbst: or maybe the evo just doesn't get the kick?
17:54 karolherbst: or well, even starts to process the request
17:55 karolherbst: so mhh, with the new code on kick we do that: "nvif_wr32(&dmac->base.user, 0x0000, (push - dmac->ptr) << 2);"
17:55 karolherbst: and we do a flush before
17:55 karolherbst: does the flush happen?
17:55 karolherbst: is dmac->base.user set correctly?
17:55 karolherbst: (or whatever the code is in your version)
17:56 karolherbst: ohhhhhhhhhh
17:56 karolherbst: Riastradh: compare your evo_kick with the master one
17:57 Riastradh: Looks the same to me: nvif_wr32(&dmac->base.user, 0x0000, (push - dmac->ptr) << 2);
17:57 Riastradh: Hm.
17:57 karolherbst: ohh wait
17:57 karolherbst: mhh
17:57 karolherbst: https://github.com/skeggsb/nouveau/commit/ba45b455f
17:57 karolherbst: this seems to be a pascal only thing
17:58 imirkin: Riastradh: so iirc you were getting an evo error
17:58 karolherbst: okay sooo, before that push buffer is in actual sysram?
17:58 Riastradh: The 3.15 code works fine, and the 4.4 code works in Linux but not in NetBSD.
17:58 karolherbst: imirkin: timeout waiting for a response
17:58 imirkin: or was that a side-effect of the evo_sync not working?
17:58 Riastradh: imirkin: Here are the symptoms that seem wrong:
17:58 Riastradh: - evo_sync fails every time
17:59 Riastradh: - there's a disp error interrupt
17:59 Riastradh: - the screen is blank
17:59 karolherbst: also that comment "Pascal added support for 47-bit physical addresses, but some parts of EVO still only accept 40-bit PAs."
17:59 imirkin: karolherbst: G84.
17:59 karolherbst: right
17:59 Riastradh: The first symptom appears to be new. The second symptom was there with 3.15. The third symptom is, well, the problem.
17:59 karolherbst: but
18:00 karolherbst: 40 bit PA is valid for all gpus
18:00 karolherbst: afaik
18:00 imirkin: it is.
18:00 karolherbst: sooo if the push buffer is in sys memory
18:00 karolherbst: and you need more than 40 bits?
18:00 imirkin: 40-bit GPU VA
18:00 karolherbst: ohh right
18:00 karolherbst: silly me
18:00 imirkin: in any case, i doubt that his laptop has more than 1TB of physical ram
18:00 karolherbst: true
18:01 karolherbst: okay, so that push buffer is inside system memory
18:01 karolherbst: I kind of assumed it was always in vram
18:02 karolherbst: Riastradh: okay, same thing: try to read system memory from 0x700000
18:02 karolherbst: so apperantly that bo to do the push bufs for evo are in system memory (my mistake)
18:02 karolherbst: you should be able to confirm that and able to read it out via mmio
18:03 karolherbst: (hopefully)
18:04 imirkin: can you read sysmem via the imem thing?
18:04 imirkin: i thought you had to feed it a GPU VRAM PA...
18:05 Lyude: imirkin: glad all the vbioses/traces I've been uploading are coming in handy :)
18:05 imirkin: Lyude: well ... kinda
18:05 imirkin: can you tell me about the NV124 traces?
18:05 Riastradh: Hm.
18:05 imirkin: i mean - what's the GPU?
18:05 imirkin: what outputs does it physically have?
18:05 Riastradh: The dmesg I have suggests that the sync buf is in VRAM.
18:06 imirkin: Lyude: oh nm. i have the vbios don't i
18:06 Riastradh: Oh, wait, maybe not.
18:06 Lyude: imirkin: :p
18:06 Riastradh: BAR 1 is GPU VA?
18:06 barteks2x: Has there been any progress in nouveau + multithreading in the last year?
18:06 rhyskidd: Lyude: thank you!
18:06 Lyude: Jfyi: every GPU I have is two DVI, one HDMI, one DP
18:06 Lyude: rhyskidd: np!
18:06 barteks2x: I remember there being some patches, but they are gone and outdated now
18:06 Lyude: Unless it's one of the laptops, but I usually mark those specially
18:07 imirkin: Lyude: ok, thanks
18:07 imirkin: Lyude: do you have access to this gpu atm?
18:07 karolherbst: barteks2x: nothing public so far afaik, there has be some work, but things got stalled as skeggsb was occupied with other things :/ And he is basically the only one with enough knowledge+time to fix it, if he has time
18:07 imirkin: Lyude: or any GM20x
18:08 Lyude: imirkin: unfortunately no, it's all at the office atm and I didn't leave it hooked up. I'll be back there on Tuesday though
18:08 imirkin: Lyude: ok. if you can, i'd appreciate a mmiotrace with hdmi plugged into something
18:08 imirkin: if it can be plugged into a hdmi 2.0 sink, that'd be even better
18:08 Lyude: Sure thing, I'll set a reminder
18:09 imirkin: (most 4k tv's, probably newer monitors)
18:09 karolherbst: imirkin: if some FHD HDMI 1.4 thing is enough, I could just make such a trace in a few minutes though, but yeah, no 4k and no hdmi 2.0
18:09 imirkin: karolherbst: well, the 4k isn't the interesting part
18:09 imirkin: i just want to see scrambling
18:10 imirkin: karolherbst: well, if it's not difficult, worth a shot. GM20x though -- i got GP10x covered
18:10 karolherbst: it is a gm2014
18:10 karolherbst: *gm204
18:10 Riastradh: karolherbst: Sure looks like it's allocated in VRAM: https://nxr.netbsd.org/xref/src/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_nv50_display.c#2622
18:10 karolherbst: Riastradh: what about the command buffer
18:10 barteks2x: well, then my nvidia GPU is going to keep being there unused until it's fixed
18:10 imirkin: Riastradh: the sync buffer is where the gpu writes back values
18:10 Riastradh: Oh, pushbuf, not syncbuf, moment.
18:12 karolherbst: barteks2x: yeah, hopefully we get all that stuff done this year, as we have to rework our memory API anyway for vulkan, so the plan was to do all that in one go (threading issues fixes + memory API rework)
18:12 Riastradh: OK, that's allocated from system RAM with dma_alloc_coherent in Linux, right?
18:12 Riastradh: https://nxr.netbsd.org/xref/src/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_nv50_display.c#320
18:12 karolherbst: should be
18:13 imirkin: Riastradh: you could try just allocating it in vram btw
18:13 karolherbst: Riastradh: but then look at the patch I linked to ;)
18:13 barteks2x: would be great, because as it is nvidia+bumblebee setup doesn't really work that well (when I tried it several days ago, glxgears segfaulted instantly)
18:14 Riastradh: karolherbst: You mean <https://github.com/skeggsb/nouveau/commit/ba45b455f>?
18:14 karolherbst: Riastradh: yes
18:14 Riastradh: This machine has a couple gigabytes of RAM (and G84<Pascal?), so that seems unlikely, but OK.
18:14 karolherbst: no
18:14 karolherbst: not that part
18:14 karolherbst: I mean, if you want to place it inside VRAM
18:14 karolherbst: then you need to allocate VRAM
18:14 karolherbst: that is just that one bit field set
18:15 karolherbst: that's the boring part
18:15 karolherbst: the more important part is the VRAM flushing
18:15 Riastradh: Ah, OK.
18:15 karolherbst: or rather BAR1 flushing
18:15 imirkin: too much has changed
18:15 imirkin: for that to be applied
18:15 Riastradh: Is there a substantive difference between pci_alloc_consistent and dma_alloc_coherent that I need to be aware of here?
18:15 karolherbst: yeah, but to get the general idea for what has to be changed
18:16 Riastradh: imirkin: I think the point is jus tthat I need to write 1 to 0x70000 and wait for it to become 2 before the write in evo_kick.
18:16 karolherbst: yeah, that is the flushing part
18:17 Riastradh: Looks like pci_alloc_consistent is just a thin wrapper around dma_alloc_coherent, so `no'.
18:18 karolherbst: Riastradh: thing is, I don't know how difficult it is for you with your current code to allocate it inside vram
18:19 karolherbst: it could also be that something is wrong with the dma setup and that's why evo doesn't get the commands
18:20 Riastradh: What do I use for dmac->handle -- passed as .start in nvif_object_init(NV_DMA_FROM_MEMORY)?
18:20 Riastradh: That is, if I were to allocate it from VRAM?
18:21 Riastradh: As is, dmac->handle is a bus address for a DMA controller.
18:22 imirkin: same as the sync object
18:22 Riastradh: Huh.
18:22 Riastradh: That's...interesting.
18:22 Riastradh: syncbuf is disp->sync->bo.offset, which I thought was a GPU vaddr.
18:22 imirkin: (i.e. VRAM, etc)
18:23 Riastradh: Oh, but a different kind of object.
18:24 Riastradh: We have NV_DMA_FROM_MEMORY {.start = dmac->handle} and NV_DMA_IN_MEMORY {.start = disp->sync->bo.offset}.
18:27 Riastradh: So, I should use NV_DMA_IN_MEMORY {.start = dmac->push->bo.offset}, if I make dmac->push a VRAM bo?
18:40 Riastradh: How are they different? I'm getting dizzy trying to read nvkm/engine/dma/base.c.
18:48 karolherbst: imirkin: I would do the trace now if you are still interested?
18:48 imirkin: i am
18:49 karolherbst: nvidia-drm.modeset=1 set + HDMI connected at loading time?
18:49 imirkin: whatever method you want to cause a picture to appear on the HDMI screen
18:49 karolherbst: anything special?
18:49 karolherbst: ahh okay
18:49 imirkin: nope
18:49 rhyskidd: karolherbst: I tried that nvbios multipart bios patch you provided
18:49 rhyskidd: worked for GP108 and GV100
18:49 rhyskidd: lots less errors
18:50 imirkin: karolherbst: just trying to look for how the infoframe is sent
18:50 rhyskidd: i did notice that my GP107 (which apparently only has one BIOS par) reported this difference in nvbios output: https://paste.fedoraproject.org/paste/296-QKYAjVPezZzRG7Gx0A
18:50 karolherbst: imirkin: okay
18:50 imirkin: and hopefully observe the HDMI scrambling setting
18:50 imirkin: which would be disabled here
18:50 rhyskidd: looks odd that the BIOS part 0 is now reported "at" the same offset as the size
18:50 rhyskidd: bug?
18:50 karolherbst: imirkin: I just have some scripts where I have nvidia+nouveau blacklisted, but the initramfs loads one of those... have to remember how to disable that :D
18:51 karolherbst: ahh, found it
18:51 karolherbst: I think
18:51 imirkin: in Lyude's vbios, there's nothing plugged into hdmi, and things look all weird, so ... i'm hoping that this will not look all weird :)
18:51 imirkin: s/vbios/mmiotrace/
18:52 Riastradh: OK, are in/from/to memory just different devices, with the same mmio register structure, but interpreting the addresses programmed into them differently?
18:52 imirkin: Riastradh: the year was 1999
18:52 imirkin: you had totally different memory spaces
18:53 imirkin: and you had to say which one you were talking about
18:53 imirkin: hence dma objects were born
18:53 imirkin: a dma object would include a base address, and say which kind of memory it was using
18:54 imirkin: starting with G80, this all got unified in GPU VA's. however the stupid dma objects lived on. they were mostly gone but kinda there. starting with fermi, they're totally gone from all the 3d stuff, but they persist in the EVO logic.
18:54 Riastradh: Oh, I see, there's also a .target parameter.
18:54 Riastradh: NV_DMA_V0_TARGET_*
18:54 rhyskidd: karolherbst: the diff for a GV100 looks much improved with your patch https://paste.fedoraproject.org/paste/Bmi7TLCYSPfVlyIhSXVJPQ
18:54 karolherbst: rhyskidd: yeah
18:54 rhyskidd: can see the fuc table within the vbios etc
18:55 karolherbst: rhyskidd: even the power budget makes sense, surprising
18:55 imirkin: so ... you create like 2 dma objects -- one for vram, one for gart
18:55 imirkin: and reuse them a whole bunch
18:55 imirkin: before this stuff used to matter
18:55 Riastradh: What's the difference between NV_DMA_{IN,FROM,TO}_MEMORY, then?
18:55 imirkin: but not so much anymore
18:55 rhyskidd: and BASE CLOCK (boost is within +/- 3Mhz of the marketing reported boost clock; base clock is right on)
18:56 imirkin: Riastradh: sorry, you'll have to RTFS for that
18:56 karolherbst: rhyskidd: yeah
18:56 Riastradh: Well, I did, and I don't see a difference...
18:56 karolherbst: rhyskidd: I mean, if you look at the patch, the stuff is quite trivial, but ... still why
18:57 karolherbst: I don't know if we actually know what that region is
18:57 karolherbst: it looks like random shit
18:57 Riastradh: They only appear in identical entries in a table:
18:57 karolherbst: meaning it is probably crypto stuff
18:57 Riastradh: https://nxr.netbsd.org/xref/src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/dma/nouveau_nvkm_engine_dma_base.c#156
18:58 Riastradh: Maybe it corresponds with some other table's order?
18:58 imirkin: no
18:58 imirkin: the actual values have significance
18:58 Riastradh: Urgh.
18:58 imirkin: look at how they're used to understand
18:58 imirkin: (they have significance to the GPU)
18:59 karolherbst: imirkin: what is totally annoying with that laptop is, that HDMI doesn't work unless you have an actual FB driver, not even the bios menu shows up
19:00 imirkin: =/
19:01 karolherbst: at least you know when you load nvidia, as the dsiplay starts to display the tty
19:02 karolherbst: same with DP though
19:02 karolherbst: only the internal screen shows firmware stuff
19:03 rhyskidd: any takers for a r-b on: https://github.com/envytools/envytools/pull/161
19:04 karolherbst: rhyskidd: uff... I had a patch for that already somewhere
19:05 karolherbst: rhyskidd: we need more though
19:05 karolherbst: rhyskidd: https://github.com/karolherbst/envytools/commit/24467a5a8948797c911fdc45f22d7faed1fb8b8c
19:07 karolherbst: and mmt needs patches as well
19:07 karolherbst: allthough not for that fifo stuff
19:07 karolherbst: I think
19:09 karolherbst: imirkin: https://drive.google.com/file/d/1lzvwtkF3VzKLLCWAwYYq3gCFr_pF3FhX/view?usp=sharing
19:09 karolherbst: I didn't check with demmio, but I think it should be alright
19:10 imirkin: thanks
19:11 imirkin: w00t, ok, all checks out. thanks!
19:12 imirkin: or at least kinda checks out ;)
19:20 karolherbst: imirkin: okay, so if I understood you correctly, if you call into hw_get_query_result, you have to reserve more space on the current pushbufer + mark the buffer as used, correct?
19:22 imirkin: yes
19:22 imirkin: all callers should already do that
19:22 karolherbst: mhh
19:22 karolherbst: either I am blind or nvc0_get_query_result doesn't
19:23 imirkin: link?
19:23 karolherbst: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_query.c#n70
19:24 karolherbst: q->funcs->get_query_result is nvc0_hw_get_query_result
19:24 karolherbst: obviously
19:25 imirkin: i was thinking of a diff function
19:25 imirkin: nvc0_hw_query_pushbuf_submit
19:25 imirkin: that's the one
19:25 karolherbst: ahh
19:25 imirkin: #define NVC0_PUSH_EXPLICIT_SPACE_CHECKING
19:26 imirkin: that means that BEGIN_* will not do a PUSH_SPACE
19:26 karolherbst: I see
19:26 imirkin: so you have to do it explicitly
19:26 karolherbst: mhhh
19:32 imirkin: Writing objects: 100% (860900/860900), 175.50 MiB | 11.29 MiB/s, done.
19:32 imirkin: fios is nice.
19:34 karolherbst: meh
19:34 karolherbst: slow :p
19:34 imirkin: skeggsb: if you get a min, this is my tree so far. not done yet, but it's a start -- https://github.com/imirkin/linux/commits/hdmi2
19:35 imirkin: skeggsb: what's left is to actually allow the high-freq modes through
19:35 imirkin: shouldn't be difficult, but i've run out of time for today. may try it tomorrow.
19:37 imirkin: skeggsb: i did feel a little awkward sticking it into the SOR_HDMI_PWR method, but ... eh
19:39 imirkin: maybe we should only do it if the monitor advertises scdc, but then i worry about the case where you unplug a scdc-capable monitor and plug an older one in.
19:39 imirkin: we also need to validate somehow that the higher mode will succeed, i haven't seen anything about that yet
19:39 karolherbst: imirkin: is fios giving you actually real fiber into your apartment or just coper (and they do fiber in their own stuff)?
19:39 imirkin: karolherbst: real fiber.
19:39 karolherbst: so lime 1gbit/s directly?
19:39 karolherbst: *like
19:40 imirkin: well, one fiber strand
19:40 imirkin: can do whatever you like with it
19:40 karolherbst: sure
19:40 karolherbst: but usually ISP don't give you more than 1 gbit/s
19:40 imirkin: but in theory, 1gbit... i think they've decreased it to like 900mbit now (advertised)
19:40 imirkin: it's rare that i get much over 100mbit to a single site though
19:40 karolherbst: ahh
19:40 karolherbst: yeah
19:40 rhyskidd: yeah, fios is nice
19:40 karolherbst: I have to use the crappy r8168 driver on one of my laptopts
19:40 imirkin: i can download from google at like 50MB/s no problem though
19:41 karolherbst: and after suspend it caps at 100 mbit/s ...
19:41 karolherbst: still insane how much you have to pay for that :D
19:41 imirkin: $70/mo
19:41 karolherbst: yeah, insane
19:41 imirkin: high?
19:42 karolherbst: I pay like 10$/mo for 300/100
19:42 karolherbst: and there are real fiber 1gbit things for 30$ around
19:42 imirkin: in the US, this is actually pretty cheap
19:42 karolherbst: yeah, I know
19:42 karolherbst: internet is just super expensive in the US :p
19:42 imirkin: i think it's actually europe that's cheap
19:42 imirkin: it's also expensive in e.g. africa
19:42 karolherbst: well, africa has other issues
19:43 karolherbst: they usually focus on mobile network for now
19:43 karolherbst: as this is more important
19:43 imirkin: i don't mean expensive relative to average income -- it's actually expensive.
19:43 karolherbst: true
19:43 imirkin: compared to european prices, for example
19:43 karolherbst: ahh, sure
19:45 karolherbst: depends highly on the political agenda in the countries. In coutnries like german/US where they totally fail with a proper agenda, the prices are super high :p in countries where they deem the internet to important you have LTE like everywhere and cheaper
19:45 karolherbst: *germany
19:45 imirkin: oh right, you're in CZ now aren't you
19:45 karolherbst: yeah, but same situation as in germany regarding mobile
19:46 karolherbst: and wire is just a bit cheaper
19:46 karolherbst: in romania eg you can get 1gbit for 10$/mo... this is just insane
19:46 karolherbst: and in the capital people also earn quite a lot compared to the rest of the country
19:47 karolherbst: and northern countries are pretty good about LTE connection
19:47 karolherbst: where you basically get LTE everywhere
19:47 karolherbst: fun fact, when I am on a train to germany, as long as I am in CZ, I get unlimited data through the WIFI, capped when in germany at 200MB or something
21:07 imirkin: skeggsb: oh, and the reg we program with sor_clock() has now gained some additional weirdness, so i'll have to add arguments to that func. hope that's alright.
21:13 imirkin: er i guess not, since everything will be in the ior anyays
23:23 karolherbst: imirkin: mhhh, I think those buffer issues are a result of us running out of vram
23:23 karolherbst: imirkin: sometimes I also get this instead: https://gist.githubusercontent.com/karolherbst/3f79100f200c0f95d2b7be67ee927fdc/raw/eb1ee66018ff8eb9a314c47159115f03ebaaa142/gistfile1.txt
23:24 karolherbst: or maybe running out of some other kind of memory
23:24 karolherbst: or it is some random error, caused by something else
23:29 karolherbst: but maybe we are actually leaking some VRAM?
23:31 karolherbst: mhh, happens inside nvc0_miptree_transfer_map
23:31 karolherbst: wait in nouveau_bo_map(tx->rect[1].bo, flags, nvc0->screen->base.client);
23:35 karolherbst: mhh, the wait is inside nouveau_gem_ioctl_cpu_prep
23:39 karolherbst: okay... the ioctl returns -EBUSY
23:39 karolherbst: which means, reservation_object_wait_timeout_rcu returned 0
23:43 karolherbst: mhh, so the fence just times out forever basically. mhh annoying to debug