13:50 ajax: do we use pcopy at all?
13:53 karolherbst: ajax: yes
13:54 karolherbst: jekstrand: the table resides in VRAM and you can just bind a different one if you need a different one
13:54 karolherbst: no, everything has to be in the table
13:55 karolherbst: no, 2D can't do resolves
13:55 karolherbst: for msaa we scale the image accordingly
13:57 ajax: karolherbst: example? i'm itching for something to poke at and apparently this laptop('s nvaf) is where they added it, was curious
13:57 karolherbst: ajax: either you can look at the copy stuff in vulkan or usage of NVE4_COPY
13:58 karolherbst: I recommend looking at the vulkan stuff though
13:58 karolherbst: https://gitlab.freedesktop.org/nouveau/mesa/-/blob/nouveau/vk/src/nouveau/vulkan/nvk_cmd_copy.c
13:58 karolherbst: all the NV90B5 stuff
13:58 karolherbst: ajax: ^^
13:59 ajax: oh, word.
13:59 ajax: didn't know we were that far along
13:59 karolherbst: vulkan or using pcopy?
13:59 ajax: yes
14:00 karolherbst: we arleady got triangles drawn :P
14:01 karolherbst: anyway.. also makes sense to look at the class headers directly: https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/dma-copy/clc7b5.h
14:01 karolherbst: there isn't much else though
14:01 ajax: was looking in the envytools docs and not finding much
14:01 karolherbst: yeah...
14:01 karolherbst: for vulkan we want to use nvidia headers only
14:02 karolherbst: only 3d ones are missing atm
14:02 karolherbst: kind of planning to get back to it and make sure all the compute stuff is working alright
14:05 karolherbst: ajax: but you have a literal ncaf there?
14:05 karolherbst: uhm
14:05 karolherbst: nvaf
14:05 karolherbst: that's like fermi.. mhhh
14:06 karolherbst: any plans on what you want to do with it?
14:06 karolherbst: ehh wait
14:06 karolherbst: that's tesla
14:06 ajax: is _old_ ys
14:06 karolherbst: I was _wondering_ if we could have a vulkan 0.9 level of support and use zink with it, but.... :D
14:07 ajax: i've been toying with the idea of a vµlkan subset api that's just enough to do like, blits, queue transfers, and display
14:07 karolherbst: ahh
14:07 karolherbst: yeah.. so then the vulkan stuff we have should be good enough for that
14:08 karolherbst: there is no technical reason tesla isn't supported, just we don't make sure the compute stuff isn't used by GPUs below turing etc...
14:08 ajax: replace "dri" with that so we can still have gles2 hardware drivers but with a common-ish presentation pipe
14:08 karolherbst: mhhhh
14:08 karolherbst: shit, tesla has a different command submission format
14:08 ajax: (wild far fetched, not entirely serious)
14:08 karolherbst: so can't use the vulkan stuff as it is today
14:09 karolherbst: I think...
14:09 ajax: nod. i imagine it'd be a bit like trying it on ivybridge
14:09 karolherbst: let me check
14:10 ajax: but. starting from "what does nvaf have" was literally just picking what the old mba i'm using happens to have in it as a place to start learning.
14:11 karolherbst: yeah... nv50 is different
14:11 karolherbst: annoying
14:11 karolherbst: doesn't have imms
14:11 karolherbst: or 1inc
14:12 karolherbst: ajax: anyway.. you can potentially build upon the vulkan branch though
14:12 karolherbst: most of the stuff should be equalish, just nv50 needs more work
14:13 i509VCB: <ajax> "i've been toying with the idea..." <- I know vulkan portability exists for mapping other apis to vulkan, not sure if it goes low enough for ancient hardware
14:13 karolherbst: and given that nv50 is like gl3.3 at most, I think it might even make sense to have its own vulkan driver dealing with all the crappyness nv50 has
14:14 karolherbst: use cl50* classes instead and make it work? dunno
14:15 RSpliet: Is it worth disambiguating NV50/G80/G90 from the NVAx non-IGP GPUs?
14:15 ajax: i509VCB: KHR_portability's major driver is vulkan on metal, afaict. metal might be lacking some things relative to vulkan but it's still way into dx11-class hardware
14:16 ajax: and i'm thinking like, nv30 should work
14:16 karolherbst: nv30?!? :D
14:16 karolherbst: though if you only do copies that's probably true
14:17 RSpliet: does nv30 work like... at all?
14:17 ajax: my floor for hardware i care about is "can it gles2"
14:17 karolherbst: uhm... somewhat yes
14:17 karolherbst: ajax: sooo.. nv50 it is
14:17 ajax: fair
14:17 ajax: but, i915 and r300.
14:17 karolherbst: nv30 is like GL 2.1
14:17 karolherbst: if at all
14:18 ajax: gles2 is a proper subset of gl 2.0
14:18 karolherbst: I think only nv40 is
14:18 RSpliet: According to the specs yes, but I think they had to emulate some bits and bobs to claim that?
14:18 ajax: 2.1 mostly added sRGB i think?
14:18 karolherbst: yeah.. nv30 is only 1.5
14:18 karolherbst: RSpliet: sure
14:18 karolherbst: I think all 2.x features are totally done in software
14:19 ajax: yeah, not actually enough fragment shader hardware to do glsl iirc
14:19 RSpliet: I wonder if software emu on a modern CPU isn't actually faster than a GeForce FX :-P
14:19 karolherbst: :D
14:19 karolherbst: though we do have a nv30_vertprog file
14:19 ajax: the other line in the sand for me is pcie though
14:19 karolherbst: and fragprog
14:19 ajax: life is too short to still be caring about agp
14:19 RSpliet: LOL, yeah no NV30. NV40 maybe
14:20 karolherbst: RSpliet: we do have shaders on nv30.... :D
14:20 RSpliet: Yep, but no control flow
14:20 karolherbst: ahhh.. right
14:20 RSpliet: It's not as bonkers as NV20 with "sure you can have shaders, just make sure they fit in 4 instructions"
14:20 ajax: ooh. dma-copy header has a GT212 class definition, that'd be me
14:20 karolherbst: ajax: yep
14:20 karolherbst: but you can use any "older" one as you please
14:21 karolherbst: just use 50b5
14:21 karolherbst: and you should be fine
14:21 ajax: RSpliet: that's not different from i915 tbh, re flow control
14:21 karolherbst: anyway.. nv30 is bonkers like completely
14:21 karolherbst: the nv4x GPUs I tried they were able to run gnome
14:22 karolherbst: but once I start to run glxgears my kernel crashes...
14:22 karolherbst: don't ask
14:22 ajax: karolherbst: is the oldest one that'd work, next is GF100 and i'm still tesla
14:22 RSpliet: NV30 isn't so bad. Just... well, it was all in the middle of the big programmable pipeline revolution
14:22 karolherbst: RSpliet: I meant the nouveau side of things
14:22 RSpliet: The nouveau side of things is just rough around the edges. We don't have a compiler, just an assembler
14:23 RSpliet: I think NV added some forms of control flow in NV40 if someone is ever bothered with an actual compiler for those gens
14:23 RSpliet: But it's all vec4 stuff, so unless you want to do hard compiler things you'll have to make it a NIR back-end :-P
14:24 jekstrand: karolherbst: What's the table re-bind cost like?
14:24 RSpliet: or keep it as is as a TGSI assembler of course
14:25 ajax:golf claps for "nil"
14:26 karolherbst: jekstrand: you need to invalidate caches
14:27 karolherbst: RSpliet: I am not too concerned about features, the stability is what's the issue :D
14:27 karolherbst: ajax: :D
14:27 karolherbst: yep, that's in jekstrand :D
14:30 karolherbst: jekstrand: what's the thing from an API perspective which would require us to rebind the table btw?
14:39 jekstrand: karolherbst: Thinking about future Vulkan stuff and NVIDIA doesn't like to talk.
14:40 karolherbst: at least you are having fun :P
14:41 karolherbst: but yeah.. I don't think rebinding the samplers table is something we want to allow happening too often
14:42 karolherbst: also the const buf containing the bound samplers also point into this table....
14:42 karolherbst: sounds like a messy situation overall