00:00karolherbst: ohhh no
00:00karolherbst: ehh wrong channel
00:01airlied: karolherbst: hardware vm
00:02karolherbst: airlied: eh.. just having a VM or what do you mean?
00:02airlied: pretty much, having per-client VM
00:03karolherbst: yeah well.. we have that for nv hardware a lot longer than nvidia or we would expose vulkan support for
00:03mangix: karolherbst: close enough :P
00:03karolherbst: I think NV50 got it already
00:03karolherbst: but vulkan is kepler+
00:03airlied: so you could bring up a cutdown vulkan on those for zink :-P
00:04imirkin: should be able to do vulkan on nv50 i think
00:04karolherbst: nvidia had a faulty impl for fermi afaik
00:04karolherbst: and they disabled it
00:04airlied: you just end up like intel haswell, small things don't conform and are pita to fix
00:04karolherbst: would be fun though if nv50 supported vulkan
00:04karolherbst: yeah, probably that
00:04karolherbst: nv50 doesn't have a 64 bit VA
00:05imirkin: i guess i'm not completely sure what the min requirements for vk are
00:05imirkin: karolherbst: is that a problem?
00:05karolherbst: imirkin: if you map host memory, then yes
00:05imirkin: karolherbst: kepler doesn't either...
00:05karolherbst: kepler doesn't?
00:05imirkin: all 40-bit
00:05imirkin: (including nv50)
00:05airlied: I think 40-bit is enough
00:05karolherbst: well, nv is 32 bit in shaders
00:05imirkin: 16x32-bit ;)
00:06imirkin: i.e. you get 16 32-bit segments
00:06airlied: I think you could do a reasonable nv50 vulkan, but you'd be hitting a lot of edges
00:06karolherbst: yeah, sounds like pain though
00:06karolherbst: airlied: sounds like a fun project
00:06karolherbst: but I think nv50 would be the next step
00:06karolherbst: if we could do vulkan on fermi that would be good
00:06airlied: like cayman could have done it for amd, but it was one generation of gpu
00:06karolherbst: as nvc0 is fermi+
00:07karolherbst: at least I would love to do benchmarks between nvc0 and vulkan + zink and evaluate if we find the time like ever to perf improve nvc0 (probably not) or just trash it and use zink
00:09karolherbst: I honestly don't see a path where anyone would spend much time improving perf on a GL driver in the future really
00:09karolherbst: well.. especially nouveau
00:09mangix: zink was vulkan to opengl, right?
00:09karolherbst: the other way around I think would be the better phrasing
00:10mangix: right, depends on point of view
00:12imirkin: airlied: it'd definitely be on the weak side. lots of atomic things aren't supported, esp on earlier variants, dunno if they're required on vk
00:12karolherbst: could lower it
00:12karolherbst: or just make it supported enough so that things work we care about
00:12imirkin: how do you lower atomics exactly?
00:13karolherbst: like intel lowers 64 bit atomics :p
00:13airlied: like if you can do gles3.1 then you can usually do baseline vulkan
00:13imirkin: but they have _something_
00:13karolherbst: imirkin: they don't
00:13karolherbst: not for 64 bit
00:13imirkin: karolherbst: they have 32-bit
00:13karolherbst: (at least not all memory)
00:13karolherbst: ahh yeah
00:13imirkin: karolherbst: G80 has _nothing_ iirc
00:13imirkin: G84-GT200 has global but not shared
00:13karolherbst: not even an atomic store/load?
00:13imirkin: GT215+ has shared
00:14karolherbst: cas is just optional really
00:14imirkin: i'm talking about anything
00:14karolherbst: yeah okay.. that's annoying
00:14karolherbst: but it could be a best effort impl
00:15karolherbst: write an ext to make things optional? :D
00:15karolherbst: imirkin: do we do gles3.1 on nv50?
00:15imirkin: karolherbst: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp#n1484
00:15imirkin: karolherbst: on GT215, i flipped it on
00:15imirkin: in truth, we do miss on some very minor bits
00:15karolherbst: what's missing for prev gens?
00:15imirkin: er, GT215+
00:15imirkin: for ES 3.1?
00:16imirkin: GT215 adds texgather, texquerylod
00:16imirkin: and some other small bits iirc
00:16imirkin: slightly earlier gens add shared atomics
00:17imirkin: (looks like nva0+)
00:18karolherbst: not sure if it makes sense to bother then
00:18karolherbst: but nvc0+ would be a cool target
00:18imirkin: in practice, the "big" missing feature for GT215 on ES 3.1 is component select on tex gather
00:18karolherbst: like if anybody cares
00:18imirkin: seemed like an OK thing to just whiff on
00:19imirkin: in exchange for compute, images, etc
00:20karolherbst: anyway... I think zink would be a viable mid term solution, until we either care enough or find enough time to write a proper perf oriented driver, because if we would bring up the current one up to speed, we would rewrite it completely anyway I think
00:20karolherbst: especially with all the threaded context, shader variants and what else other drivers are doing
00:20karolherbst: state tracking has to be reworked anyway
00:21karolherbst: oh well
00:21karolherbst: depends on the actual perf in the end
00:21karolherbst: but I would say it's a safe bet to assume zink being faster
00:23airlied: I think the one area zink fails against radeonsi is compiler side
00:23karolherbst: ahh yeah, makes sense
00:23airlied: like there is CPU overhead, but mareko put a lot of work into reducing compilation/linking times
00:23karolherbst: we do the glsl -> nir -> spir-v round trip, don't we?
00:23airlied: granted LLVM as a backend made them excessive to begin with
00:24airlied: karolherbst: yes
00:24airlied: it's not really the compiler IR tsack as much as when you have to compile
00:24karolherbst: would be cool if we could do glsl -> GL spir-v -> Vk spir-v
00:24airlied: not really
00:24karolherbst: why not?
00:24airlied: jsut doesn't save you anything where you need to save it
00:25karolherbst: although I'd assume that would lower the overhead a little, but granted glsl parsing is the real killer anyway
00:25airlied: the problem is that vulkan pipelines are a big compile, and GL doesn't really fit that model
00:25karolherbst: ohh, I see
00:25karolherbst: could add more extensions or something :P
00:26airlied: there are some coming
00:26airlied: or here already
00:28karolherbst: if we keep adding ext after ext do make translation a practical no-op I guess then it really doesn't make much sense to keep a GL driver
00:29karolherbst: though the biggest advantage of caring more about vulkan are all the windows games anyway
00:29airlied: yeah with steam and proton, now GL usage is quite reduced
00:29airlied: unless you really want to tackle the workstation market
00:29karolherbst: so where it matters you have vulkan anyway and where it don't the overhead won't be a problem
00:30karolherbst: airlied: why workstation?
00:30karolherbst: legacy software?
00:30airlied: those CAD software stuff is stuck on GL
00:30airlied: and they love excessive vertex heavy workloads
00:30karolherbst: yeah sure fine.. those 5% perf difference won't kill them
00:30airlied: though mareko has optimised mesa for that in most of the generic paths
00:30karolherbst: ahh, cool
07:26mynacol: karolherbst: Running your MT fixes MR since January. Definitely better, but still freezes especially in MPV sometimes.
07:26mynacol: Will be switching to the branch with even more fixes.
23:02TimurTabi: I may have asked this before, but is there a way to write to an offset from the base address of a subdev?
23:02TimurTabi: I have a function that needs to write to a particular register in one of three different Falcons, either the GSP, the SEC, or the NVDEC (whatever that is).
23:02TimurTabi: It's the same register, but the base address is different (either 110000, 840000, or 830000)
23:03TimurTabi: I was hoping that struct nvkm_subdev would have a "u32 base_address" field or something like that.
23:29anholt: well, gm206 looks way more stable than gm20b.
23:30anholt: deqp transform feedback is still a flakefest
23:37karolherbst: mynacol: yeah.... I did not test those patches with mpv or something _at_all_
23:54airlied: skeggsb: probably a q for you above from Timur
23:54airlied: though he's gonen ow