14:24karolherbst: imirkin: any opinion on where you'd prefer to handle the SVM cutout? (https://github.com/karolherbst/mesa/commit/a9d8291d9445346402209a7b32a40d306bfe659b)
14:24karolherbst: move it rather into the nouveau_screen constructor?
14:24karolherbst: or just in nvc0?
14:24karolherbst: or somewhere else?
19:15ryszard: any news about nvidia support nouveau in older chips?
19:15imirkin: can you rephrase your question? having trouble understanding.
19:16ryszard: like GF6200?
19:16imirkin: what about it?
19:16ryszard: I was trying to run GNOME on it but it failed completely
19:17ryszard: it would be still very good hardware for everyday use without gaming or/and ML/AI
19:17ryszard: but without up to date drivers the only purppose is to return it to recycling :|
19:18imirkin: i'm still unclear on the question
19:18imirkin: or are you just here to complain about how GNOME is now requiring opengl to do anything useful?
19:19ryszard: well no, just wish to know if there anything changed in context of nvidia support for nouveau as there had been some announcement in phoronix that they are going to
19:19imirkin: no, and i find it unlikely that nvidia will ever provide any additional support for older GPUs
19:20ryszard: an it would be a chance for second life for older chips
19:20ryszard: so bad then
19:20imirkin: however if you use a less anachronistic setup, you'll find that the GF6200 is totally fine
19:21ryszard: what do you mean?
19:21imirkin: well, GNOME requires new things. use something that doesn't.
19:22imirkin: i've been using WindowMaker for the past 20+ years, working fine
19:22ryszard: but well, because of centos and fedora gnome is slowly becoming something like industry standard
19:23imirkin: can you not run WindowMaker on centos or fedora?
19:23imirkin: that seems surprising
19:25ryszard: well I
19:26ryszard: well I'm not talking exactly about the machine that I owns but when I'm somwhere outside in some institution they usually have centos or fedora with standard configuration which is gnome
19:26imirkin: i know how to operate Windows 10 even though i haven't used any MS operating system full time since Win2k
19:27ryszard: I would try enlightenment but lets face the facts - even if it is really good wm I haven't seen it in any machine for looong time
19:28imirkin: it also requires new stuff, so wouldn't help with the GF6200
19:31ryszard: didn't know
19:31imirkin: well, at least the newer versions do
19:31imirkin: i'm not talking about e16 :)
19:32ryszard: well, GPU accelereation is a desired thing when you can offload some computarions from CPU to GPU especially when GPU is idling
19:32imirkin: when the GPU is designed for such things
19:32imirkin: which the pre-DX10 GPUs quite frankly were not
19:33ryszard: well as I know they partially are, but it would have to be implemented by driver to do what they can and do rest by software - it would be always better than nothing :)
19:34ryszard: but as I suppoose it is cheaper to return old chips to recycling and get some more modern hardware
19:34imirkin: i think that's a poor analysis ... it's not necessarily better than nothing
19:34imirkin: nothing allows everything to be kept in cpu memory
19:35imirkin: something requires a lot of back-and-forth
19:35ryszard: yeah, right
19:36imirkin: and yeah, the nv30 3d driver (which covers nv4x as well) is total crap
19:36imirkin: it only handles the "fast path" cases, and doesn't deal with the fallbacks that are necessary very well
19:39imirkin: (and that hardware requires a LOT of fallbacks for conformant GL ... thing is all the games of the day knew how to stay on the fast path. but things like gnome don't.)
19:46ryszard: well, what chips should I consider to be able to run gnome and hw accelereation in firefox?
19:46ryszard: and do not have to rely on prioprietary nv drivers ?
19:48imirkin: i'd recommend AMD
19:48ryszard: i.e. I use old mainboard with AM3 socket and iGPU Radeon HD4200 which works great with gnome and firefox under fedora 32
19:48imirkin: just use the HD4200
19:48imirkin: that's evergreen iirc
19:49imirkin: which is like 3 generations ahead of the GF6200
19:50ryszard: but in another machine I have no iGPU, and major of Radeons on pcie are huge units with two huge fans and consumes > 200W ;p
19:50imirkin: get the ones that aren't :)
19:51ryszard: but yeah this iGPU HD4200 works quite stable even on wayland
19:51ryszard: it fails from time to time when waking up from suspend
19:51imirkin: e.g. https://www.newegg.com/sapphire-radeon-rx-550-100414p4gl/p/N82E16814202287
19:51imirkin: just picking one at random
19:52ryszard: yep I'm hunting now for rx550 but I prefer something weaker with passive cooling
19:52imirkin: i don't think amd puts out anything with passive cooling, unfortunately
19:52imirkin: and i can tell you that people have problems with gnome on nouveau for all GPUs
19:52ryszard: this iGPU has passive cooling ;p
19:53imirkin: doubtul. i think it's part of the CPU package, which definitely has a fan
19:54ryszard: no, this is not APU, regular Phenom II unit with iGPU in the chipset
19:54imirkin: ah ok
19:55ryszard: I've got Phenom II 965 x4 for $20 which is still quite powerfull unit for silly money, the mb can accept 32GB of RAM
19:55imirkin: i mean, there's shit like https://www.newegg.com/diamond-radeon-hd-6450-6450pe31g/p/N82E16814103187
19:55imirkin: but it's really quite bad and i would not recommend it
19:55imirkin: that's a evergreen GPU, same as your HD4200
19:56imirkin: the driver support for this isn't as good, and you'll never get vulkan. whereas the RX550 should get you vulkan out of the box
19:56ryszard: thats why I'm hunting now for rx550
19:57ryszard: but it would cost about $100 which is still quite expensive
19:57imirkin: the one i linked to was $85, although you might not be in the US?
19:57ryszard: I'm not
19:58karolherbst: ryszard: you have any more details on what fails exactly?
19:58karolherbst: maybe it's something we could add to nv.. 30?
19:58imirkin: karolherbst: nv4x. so much can fail.
19:58imirkin: so few things work
19:58karolherbst: but it sounds like it requires GLES2 or so
19:58karolherbst: and we don't expose GLES or something
19:58imirkin: no, we do
19:58imirkin: we just don't implement it ot the letter
19:58imirkin: GLES2, presumably
19:59ryszard: karolherbst: well, after GNOME started up the screen was a mess
19:59karolherbst: so just broken stuff
19:59karolherbst: maybe something would get logged out
19:59karolherbst: maybe it assumes more stuff... of stuff
19:59ryszard: and I even do not know what information you wish to get to start from
19:59karolherbst: or maybe nv30 is broken indeed
19:59karolherbst: well.. knowing what's broken _might_ help
20:00imirkin: well, i can tell you if you mix and mathc the wrong fb and depth buffer formats, then all hell breaks loose
20:00ryszard: what logs do you need? where can I get them form for you?
20:00karolherbst: ryszard: from mutter probably
20:00karolherbst: I am not good with debugging gnome
20:00karolherbst: but not working gnome sounds like something we might want to fix if that's not too painful
20:00karolherbst: probably will run like shit anyway
20:01karolherbst: but it has some low perf mode when running on llvmpipe
20:01karolherbst: so maybe it wouldn't be too bad
20:01ryszard: well I have netbook based on AMD E-350 with Radeon HD6200 and well it is quite slow on GNOME
20:01ryszard: but works
20:01karolherbst: ryszard: mind running es2_info though?
20:02karolherbst: wondering what GLES2 version we expose on that
20:02karolherbst: but.. normally xfce4 is a quite decent desktop on low perf machines
20:02ryszard: actually I tried this gf6200 in centos 7 with older gnome there
20:02karolherbst: and I usually recommend using xfce
20:02imirkin: karolherbst: we expose GLES2 on nv4x
20:02imirkin: we don't on nv3x, due to lack of NPOT (and some blending bits)
20:02karolherbst: 2.0 then I guess?
20:02karolherbst: I see
20:02imirkin: right, GLES2.
20:03imirkin: there's also GLES3 and GLES31 :)
20:03ryszard: I can't remember now what GNOME they use there, give me a sec I will check
20:03karolherbst: well.. for odd reasons gles3.2 still counts as gles2 :p
20:03imirkin: karolherbst: it's gles2-based. and it's the "GLES2" API in EGL.
20:03imirkin: but if you say you expose GLES2, that usually isn't referring to the API bit in EGL
20:03karolherbst: ryszard: anyway.. figureing what's broken might help.. I just don't have the hw here
20:04karolherbst: and maybe it's a mutter bug
20:04imirkin: we'll never know
20:04ryszard: ok, the latest centos 7 has gnome 3.28.2
20:04imirkin: i've sunk a lot of time into nv30, and made only small bits of progress.
20:05imirkin: i cleaned up a ton of stuff, but the fallbacks are still a giant pain
20:05karolherbst: imirkin: my hope is it's something obvious and either mesa complains or.. mutter
20:05imirkin: lol ok
20:05imirkin: good luck.
20:07ryszard: lol it didn't sound good ;p
20:07karolherbst: it's not
20:08karolherbst: imirkin: btw, saw my question about the DRM_NOUVEAU_SVM_INIT stuff?
20:08imirkin: i did, but i didn't look :)
20:09karolherbst: well.. you don't really have to look either.. just a question of where it makes the most sense to call it
20:09karolherbst: it has to happen before the VM gets allocated
20:09karolherbst: right now I do it in the winsys
20:09karolherbst: but maybe in nouveau_screen it makes more sense.. or even nvc0_screen
20:09karolherbst: no idea
20:09imirkin: right, but i have to look to properly understand what `it` is
20:14karolherbst: mhh, it enables SVM on the VM, meaning the GPUs and the applications VMs is the same.. and it only works on compute engines. In order to enable it, the application needs to cutout an area for driver private bo allocations :/
20:14karolherbst: I kind of wished we could do that only for OpenCL, but skeggsb said it doesn't matter if we enable it anyway
20:15imirkin: didn't we discuss this?
20:15imirkin: add a new pipe cap
20:15karolherbst: that's the user ptr support, sure
20:15karolherbst: but we also have to enable it first
20:15imirkin: this is something else?
20:16imirkin: ok, i guess i really need to look at your patches
20:16imirkin: will do ... later
20:16karolherbst: because.. you need to reserve some of your vm space
20:16imirkin:is so lazy
20:16imirkin: oh yeah, just always do it
20:16imirkin: vm space is infinite
20:16imirkin: on those GPUs, it's 48-bit?
20:17karolherbst: we need 40 bits because of ... stupid reasons
20:17karolherbst: some engines can only handle 40 bit addresses
20:17imirkin: so small.
20:17karolherbst: doesn't matter
20:17karolherbst: I am just wondering where I should put the code doing all of that
20:17karolherbst: right now I reserve the next POT of the vram_size.. and less on 32 bit systems.. but those are just details