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