00:36 karolherbst: imirkin: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/f3d15358879816303b1a8343489f5e3deee4a1f8
00:36 karolherbst: codegen printed the wrong sys val, I got confused :)
01:25 imirkin: oops
01:28 karolherbst: imirkin: maybe worth putting a static assert in places as well
01:30 imirkin: go for it
01:31 karolherbst: yeah.. will do tomorrow
10:33 raket: skeggsb: GK110 2K/144hz/Displayport. It seem to do the modeset, monitor announce 144hz in OSD. There is signal, just no picture. https://www.youtube.com/watch?v=bx13R5_E-30
14:33 karolherbst: imirkin: uhh.. can it be that TexInstruction::getIndirectS is broken since forever?
14:33 karolherbst: or is that intentional?
14:34 imirkin: intentional
14:34 imirkin: (probably)
14:34 karolherbst: yeah...
14:34 imirkin: indirect-s is not supported.
14:34 karolherbst: ohh..
14:34 karolherbst: I see it used in some lowering code
14:34 imirkin: yeah, there's some semi-bogus lowering code
14:34 imirkin: but indirect s never happens
14:34 imirkin: i think.
14:34 karolherbst: okay
14:34 imirkin: or it's always == indirect r
14:34 karolherbst: nope
14:35 karolherbst: well...
14:35 imirkin: in practice.
14:35 karolherbst: you can set the indirect
14:35 karolherbst: yeah..
14:35 imirkin: you can set it.
14:35 karolherbst: right
14:35 imirkin: but it's not set.
14:35 imirkin: ;)
14:35 karolherbst: jep
14:35 imirkin: basically indirect-s makes sense for fermi
14:35 imirkin: but for kepler it's all bindless.
14:35 imirkin: i guess ... hm ... maybe it'd be ok
14:35 karolherbst: I just wanted to print the indirects, and saw that both are the same even though only r is set :)
14:35 karolherbst: I mean.. I can use the fields directly..
14:35 imirkin: since the indirect handle is sampler | tex
14:36 imirkin: yeah, iirc we just set them to the same value
14:36 karolherbst: it always annoys me that you can't see the indirects :)
14:36 imirkin: yes
14:36 imirkin: slightly
14:36 imirkin: lots of minor problems with the printer
14:37 imirkin: basically the thing with indirect s is ...
14:37 imirkin: we don't provide a separate of sampler binding values
14:37 imirkin: we only provide a single unified table to look up from
14:37 imirkin: so indirect-s can't work in that scenario
14:37 imirkin: we could provide a second "samp" table, do the lookup in there
14:37 imirkin: but ... we're lazy.
14:37 imirkin: coz it's all moot in GL
14:38 imirkin: this stuff only matters for DX (and now, VK)
14:38 karolherbst: or indirects :p
14:38 karolherbst: c
14:38 imirkin: for indirects it's fine.
14:38 imirkin: coz r == s
14:38 imirkin: (for GL)
14:38 karolherbst: ohh right. I meant printing those at all
14:38 imirkin: therefore, indirect-r == indirect-s
14:39 karolherbst: "sustp 2D $r0+%r25 $s0 rgba u32 # %r17 %r18 %r21 %r22 %r23 %r24 (0)"
14:39 imirkin: cool. $r0 seems wrong.
14:39 karolherbst: any better idea of how to print them?
14:39 imirkin: oh
14:39 imirkin: i see.
14:39 karolherbst: imirkin: it's an indirect actually
14:39 karolherbst: :p
14:40 imirkin: r[0+%r25]
14:40 karolherbst: yeah... I hope this doens't make the code too ugly
14:40 imirkin: the s makes no sense for su* ops
14:40 imirkin: on any gen.
14:40 karolherbst: still printed though :p
14:40 imirkin: i know
14:40 karolherbst: but yeah...
14:40 karolherbst: doesn't matter
14:42 karolherbst: sustp 2D $r[0+%r25] $s0 rgba u32 # %r17 %r18 %r21 %r22 %r23 %r24
14:44 karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/848376033900cb0b51ac880cb91a8a772e0fd1d6
14:47 karolherbst: mhhh
14:47 karolherbst: "$p0 sustp 2D $r[2+$r3] $s0 rgba f32 # $r0d $r4q $r3"
14:47 karolherbst: seems like we never clear the indirect
14:47 imirkin: yeah, no need to :)
14:48 imirkin: see what you got yourself into?
14:48 karolherbst: yeah.. but that's a bit confusing now
14:48 karolherbst: imirkin: maybe just set the src to -1 when lowering?
14:48 karolherbst: but.. there are a few places ;/
14:49 karolherbst: :/
14:49 imirkin: don't really care ... just don't break actual logic.
14:50 karolherbst: ohh.. we just never fix it up in setIndirectR.. that's easy then
14:50 karolherbst: uhm... mhhh
14:51 imirkin: see why i told you to just go to the beach? :)
15:13 linkmauve: I now have a third GPU in my desktop, someone gave me a RX580. \o/
15:16 imirkin: linkmauve: nice!
15:17 imirkin: linkmauve: this is what i currently have in my system :) https://paste.debian.net/1152199/
15:17 imirkin: 20 years of GPU in one machine
15:17 linkmauve: <3
15:18 linkmauve: I could plug in my 6600GT and Radeon 9600 too I guess.
15:18 imirkin: eventually you run out of slots, no?
15:18 linkmauve: Is PCI compatible with PCIe?
15:18 imirkin: the physical plug? not without a _lot_ of force
15:18 linkmauve: ^^'
15:19 linkmauve: How is your Riva TNT2 plugged in, AGP?
15:20 imirkin: PCI
15:20 linkmauve: Oh, so you have both PCI and PCIe slots?
15:20 imirkin: yes
15:20 imirkin: 2 pcie x16 and 2 PCI
15:21 imirkin: (and some pcie x1 and x4 mix)
15:24 linkmauve: According to the marketing page, mine has “3 PCIe 3.0 x16, 2 PCIe 3.0 x1” only.
15:24 linkmauve: No PCI. :(
15:25 imirkin: not gonna peek inside? maybe they threw one in behind marketing's back!
15:25 imirkin: heh
15:25 linkmauve: I don’t even remember how they look like. :x
15:25 linkmauve: But it’s open right besides me.
15:25 imirkin: yeah, i think PCI is harder to find on new motherboards these days
15:25 imirkin: this one is 10 years old
15:26 imirkin: so it was quite common to have back then
15:26 imirkin: linkmauve: https://en.wikipedia.org/wiki/Conventional_PCI
15:26 imirkin: there are a number of variants... 5V vs 3.3V, with the notch in different places
15:27 imirkin: and then 64-bit (and maybe even 128-bit?) variants, with longer slots
15:27 linkmauve: Makes sense, to avoid people plugging in wrong cards in the wrong slot.
15:27 imirkin: right. and most cards had notches in both places and supported both voltages.
15:27 imirkin: i believe 5V was the initial thing, and then they moved to 3.3V? i forget.
15:28 linkmauve: Same as Nintendo going from the GameBoy to the GameBoy Advance.
15:28 imirkin: yes. JUST LIKE THAT
15:28 linkmauve: Where cartridges were made smaller in order not to fry them plugging them into a DMG.
15:29 imirkin: DMG?
15:29 imirkin: GBA is after my time
15:29 imirkin: i'm aware of its existence, but not much beyond that
15:30 linkmauve: DMG was the original GameBoy.
15:30 imirkin: oh
15:34 linkmauve: Dot Matrix Game, right.
19:04 karolherbst: imirkin: mhh.. do I have to order vertex inputs? or is there something special with that id field?
19:05 imirkin: well, they have to correspond to how the application is setting them...
19:05 imirkin: can't just randomly reassign locations...
19:05 karolherbst: ohh wait.. id is not used at all
19:05 imirkin: (that'd be nice)
19:05 imirkin: not sure what specifically you're referring to
19:05 karolherbst: https://gist.github.com/karolherbst/d042ae94e59bda9e491307eac24acbf7
19:05 karolherbst: I'd assume this is "equal"... but I guess the order matters actually
19:06 imirkin: never seen it before.
19:06 imirkin: is it set anywhere to != 0?
19:06 imirkin: (check nv50 too)
19:07 karolherbst: it's set for outputs
19:07 imirkin: (nv50 has a remapping stage, i haven't read that code since i added GS support to nv50 in ... 2013?)
19:07 karolherbst: and inputs except vertex
19:07 imirkin: ok
19:08 karolherbst: ohh..
19:08 karolherbst: okay.. vertex shaders are indeed special
19:08 karolherbst: and the order actually matters
19:08 karolherbst: it seems
19:08 imirkin: it's always just about the locations
19:08 imirkin: order never matters
19:08 karolherbst: well
19:08 karolherbst: so those both configurations are equal?
19:09 karolherbst: anyway.. the header also gets set up differently
19:09 karolherbst: I just think there is somethign special going on for vertex shaders
19:09 imirkin: hard to tell exactly, but looks like it
19:10 karolherbst: yeah.. but the first one works the latter not
19:10 imirkin: i'd expect there's something else going on
19:11 karolherbst: mhh.. let me check
19:12 karolherbst: ehh
19:13 karolherbst: the locations are messed up actually
19:13 karolherbst: uff..
19:13 karolherbst: ohhh
19:13 karolherbst: imirkin: nvc0_vp_assign_input_slots
19:13 karolherbst: it only uses the index
19:13 karolherbst: not .si
19:14 karolherbst: so nothing matters except the order
19:14 karolherbst: I guess I can fix that to be more flexible..
19:14 imirkin: hmm
19:14 imirkin: odd.
19:14 imirkin: ok
19:14 imirkin: i very rarely look at that stuff.
19:14 imirkin: oh right
19:14 imirkin: so with TGSI, you don't get semantics
19:14 imirkin: for vertex inputs
19:14 imirkin: it's just IN[0], etc
19:14 imirkin: but it's the 0 in IN[0] which matters
19:14 karolherbst: yeah.. I just cleaned up all my input/output handling and made the code way cleaner.. but now I have this kind of fallout :)
19:15 karolherbst: yeah...
19:15 karolherbst: I saw
19:15 imirkin: like it could be declared as IN[1] then IN[0], and it should still work
19:15 karolherbst: tgsi also just sets the index while iterating
19:15 karolherbst: right
19:15 karolherbst: but tgsi also sets the .si field correctly
19:15 karolherbst: so..
19:15 imirkin: i don't think i've seen semantics associated with vertex inputs in tgsi
19:16 karolherbst: yeah.. they are not
19:16 karolherbst: tgsi does this:
19:16 karolherbst: info->in[i].sn = TGSI_SEMANTIC_GENERIC;
19:16 karolherbst: info->in[i].si = i;
19:16 karolherbst: and i is the iterator over the inputs :)
19:16 imirkin: ok. maybe they're not printed then.
19:16 imirkin: oh
19:16 imirkin: you mean the nouveau code does this
19:16 karolherbst: yes
19:16 imirkin: but in TGSI there is no semantic
19:16 imirkin: we just do that to normalize i guess
19:16 karolherbst: right
19:31 karolherbst: okay.. so slowly I am getting the hang out of all of this