07:09mupuf: Lyude: Looking real good for a first series in IGT :o
07:17mupuf: as for the kernel patch, good reason for 2/2, but I won't pretend I can review it without spending hours on it
07:31cryptix: Hi! my sway/wayland setup broke after I upgrade to an RTX3070 (some DRI error). I'd love to help testing patches if there are any but between the kernel and mesa I'm a bit lost where I'd even start looking... :D
07:37HdkR: Probably because Nouveau doesn't support 3D acceleration on Nouveau?
07:37HdkR: er, on Ampere*
07:45cryptix: hm.. yea, i figured as much. I just found the feature matrix and seeing that nv140 and nv160 are also marked as TODO, I guess support is further out than I assumed. That being said I have around 10years systems development experience on my belt and would like to help, I just need a bit of guidance.
10:28damo22: cryptix: maybe you can guess the key to the firmware signing :P
10:31cryptix: oh nooeee... that sounds terrible. let me rephrase to see if i understand. There is a blob to be reversed and implemented which is uploaded to the card that needs to signed and is checked on the card?
10:34cryptix: that sounds like it needs a manufacturer who forgot to remove their JTAG pins from a revision their of cards or some such. damn
10:37RSpliet: Yes, but without the JTAG
10:38RSpliet: If you happen to have an academic-grade microscope that is good enough for reverse engineering microchips produced at 14nm, this may not be the task for you
10:40RSpliet: Otherwise... well, we just need the GR firmware, NVIDIA usually provides that. And then a lot of mesa changes to support the new chips which are more software-engineery tasks
10:40RSpliet: Heard the changes aren't that invasive compared to the previous gen (no new ISA?)
10:42cryptix: hmm yea... Nope on the microscope, I fear. Humor me: GR stands for... ?
11:08RSpliet: GRaphics. The compute-and-rasterise part of the chip (as opposed to display, or DMA/memory, or performance management...)
14:33imirkin: cryptix: nvidia releases blobs that enable, essentially, accel. and they haven't released those yet for ampere
14:33imirkin: they're usually behind by a year or so
14:33imirkin: all the bits are ready afaik, they just have to release something to linux-firmware.
14:34kherbst: RSpliet: well, there are other ways :p
14:59imirkin: Lyude: for your IGT stuff, i think you need to blacklist pre-nvc0 somewhere?
15:00imirkin: oh, i guess the do_or_die thing will cover that...
16:35Lyude: imirkin: we also wouldn't have CRC hooked up for pre-nvc0 anyway
16:35imirkin: Lyude: sure, but don't want stuff to crash
16:36imirkin: anyways, the do_or_die seems fine
17:55kreyren: Is there a way to do reclocking on GPU without a driver
17:56kreyren: like injecting voltage to somewhere
17:58RSpliet: kreyren: the only way to do that is by *being* the driver
17:58RSpliet: e.g. doing all the poking around registers manually
17:58RSpliet: because changing clock speeds is hard
17:59RSpliet: If the earth suddenly started revolving 10x as fast, you'd fall over. Same happens if you just change a clock. You need to brace it, and let it compensate where necessary
17:59kreyren: so how would it deal with me adding more amperage? It can somehow compensate for the additional power or ? O.o
17:59TimurTabi: Anyone here know what the "page" parameter in nvkm_ram_get() is supposed to be? I can't figure it out from just looking at the source code.
17:59TimurTabi: I'd ask Ben, but he's on vacation.
18:14imirkin: TimurTabi: can you make it a multiple choice question?
18:18TimurTabi: Sadly, no. It appears to be some kind of alignment value, but as a shift value. The code just seems a little weird.
18:18imirkin: so you have your answer then?
18:18imirkin: basically there are different sized pages
18:19imirkin: there are 4k pages, 64k/128k, and some-number-of-mb pages, depending on gpu generation
18:19imirkin: similar to x86
18:19TimurTabi: Ah, it's supposed to reflect the GPU's memory page size.
18:19imirkin: individual pages may be different sizes
18:19imirkin: same as on e.g. x86
18:20TimurTabi: ok, I think that's all I needed.
18:20imirkin: where you can have 4k pages, 2 (or 4?)MB pages, and "huge" pages (1-4GB, i forget)
18:20imirkin: different size pages also support different things
18:20imirkin: (like compression, etc)
18:21TimurTabi: ok, thanks.
18:21imirkin: you can look at like vmm* in subdev/mmu for the various restrictions
20:35imirkin: pmoreau: let me know if you plan on completing review of the nv50 compute shader prep MR. if not, i'll just push.
22:41exit70[m]: would imac with kepler gpu (2012-2013, a potential upgrade for 2009-2011) work reasonably well with nouveau?
22:41imirkin: it should. but mac platforms frequently bring their own challenges
22:43imirkin: Lyude: on the cursor thing, i also don't know that e.g. a y-offset would be supported.
22:43imirkin: since i sorta assume the start address has to be aligned to something
22:44Lyude: imirkin: yeah we probably need to check that there's no offset being used as well
22:44RSpliet: exit70[m]: PowerPC+nouveau is definitely a challenge... when did they jump ship again?
22:44imirkin: RSpliet: well become kepler ;)
22:44imirkin: RSpliet: the latest PPC G5's came with a NV4x
22:45RSpliet: yeah, 2006 is what I'm reading
22:45imirkin: become -> before, obviously
22:45imirkin: that's a weird typo
22:45imirkin: i dunno what's going on with my fingers
22:45RSpliet: blame autoincorrect
22:46imirkin: Lyude: or you can just disallow any funny business by requiring the w/h to be right :)
22:46Lyude: imirkin: no-igt has a legitimate reason related to intel hw to be doing that in the test, we're lucky that they change the height and not the width though
22:47Lyude: anyway-i'm adding quirks like this to a list of things to eventually write tests for that are nvidia specific
22:49exit70[m]: off topic, the latest g5 has pcie. ppc64 people are using r600 capable (before southern islands) cards (still use the original nv card for boot afaict)
22:50imirkin: exit70[m]: i knew it had pcie, surprised that r600-class stuff works OK on it
22:52exit70[m]: in the intel mac era the dgpu shipped went back and forth before it settled on amd
22:53imirkin: with intel, sure
22:53imirkin: but i'm surprised that there's a GL 4.5-capable driver that works on BE
22:53imirkin: or even GL 4.3 for that matter
22:54exit70[m]: up to 3.2 according to https://docs.voidlinux-ppc.org/configuration/graphics.html
22:54imirkin: someone must have done a bunch of work to make that happen
22:54imirkin: go someone
22:56imirkin: GeForce FX definitely doesn't expose GL 2.1 with nouveau (and i sorta assume not with blob either, unless they have *crazy* amounts of fallbacks)
22:57exit70[m]: yeah yeah. i am interested in kepler because they are supported by at least macos catalina and they are modernish by themselves?
22:57imirkin: yeah, kepler is plenty modern
22:57imirkin: and probably the best-supported family of any by nouveau
22:58imirkin: you don't have a few of the newer more esoteric features, but i doubt it'd be particularly noticeable
23:02exit70[m]: i see i see guess i could test it out using a live system first
23:03imirkin: the main thing that's good about kepler is that we support reclocking on it
23:03imirkin: (no reclocking = shit perf)
23:17imirkin: that said ... please remember that nouveau isn't a pro-level driver
23:17imirkin: we try, but it's hard to compete with well-funded teams that have access to hardware and docs
23:21exit70[m]: sure. desktop use (e.g. gnome on wayland) is what i have in mind
23:24imirkin: people have had mixed experiences with gnome/kde
23:24imirkin: works well for some, not for others
23:25imirkin: since i use netiher, never looked into it
23:34Lyude: mupuf: thank you for the reviews btw!