02:41 lovesegfault: karolherbst, imirkin any of you around?
02:41 lovesegfault: I'm trying to understand how this USBC->DP cable works
02:45 HdkR: https://www.usb.org/sites/default/files/D2T1-4%20-%20VESA%20DP%20Alt%20Mode%20over%20USB%20Type-C.pdf
02:47 lovesegfault: Oh, apparently it just works
02:48 lovesegfault: here I was thinking I would need something special to test this
02:48 lovesegfault: 4K 60Hz here I come!
02:48 lovesegfault: HdkR: Thanks for the link, I'm reading through it right now
02:51 lovesegfault: imirkin: Interesting, the weird lag/low refresh/high latency feeling that I had is gone now that I'm using DP
02:51 lovesegfault: I thought it was the buffer copy in the compositor, but apparently the move to DP fixed it
02:59 lovesegfault: Hmm, scratch that, it still exists but it does seem to be _better_
04:41 kelleymcches: Not sure if this is the best place to find out if there is a solution, but there is a strange issue with the nouveau driver in my console (this is persistent across pretty much all of the distros I have used, but I am currently using Gentoo). When I use the nouveau driver with my monitor (an ultrawide 2560x1080 monitor), it seems to format the screen in a way where each row of pixels is offset, making everything unreadable (I do have a
04:41 kelleymcches: picture of it for a better look). The only thing that seems to fix it is using "nouveau.modeset=0" in my kernel command line. Any ideas on what could fix this? My GPU is an RTX 2080. (I went through the troubleshooting section to make sure that the correct kernel settings are enabled.)
04:42 imirkin: karolherbst: so i think a simpler solution is to just use _mesa_base_tex_format and make sure it's the same + write a new function with all those same foramts which just returns like the number of bits in the first format. that should be enough to compare.
04:43 imirkin: er, in the first *component*
04:43 lovesegfault: kelleymcches: What kernel version? what GPU? DP or HDMI?
04:43 imirkin: kelleymcches: do you have a pic?
04:44 imirkin: the troubleshooting section is basically bogus at this point. it made more sense ~10y ago =/
04:44 kelleymcches: lovesegfault: the kernel version is 5.4.28, the gpu is an RTX 2080, and i'm using displayport.
04:44 kelleymcches: imirkin: hold on while i upload it to imgur
04:45 imirkin: kelleymcches: also pastebin boot log wouldn't hurt, although i doubt that will have the smoking gun
04:45 imirkin: based on your initial description, sounds like the pitch is somehow wrong
04:45 kelleymcches: alright here's the image link: https://imgur.com/a/Dw3N5Pv
04:46 lovesegfault: kelleymcches: that link seems invalid to me
04:47 kelleymcches: lovesegfault: sorry about that here's the actual link https://imgur.com/a/DW3N5Pv
04:48 imirkin: heh
04:48 lovesegfault: Wow, that's a cool effect :P
04:48 imirkin: kinda feels like the fb is like 640px wide but is getting programmed as 2560 or whatever
04:48 kelleymcches: yeah it's weird haha. i'm just uploading the pastebin right now
04:49 kelleymcches: here's the pastebin: http://termbin.com/37kp
04:49 imirkin: 2560/5 = 512, which isn't a common thing... hm
04:50 imirkin: [ 0.934483] nouveau 0000:09:00.0: DRM: allocated 2560x1080 fb: 0x200000, bo 000000007d312643
04:50 imirkin: that's good
04:50 imirkin: [ 5.077138] nouveau 0000:09:00.0: DRM: wndw-0: timeout
04:50 imirkin: [ 7.077108] nouveau 0000:09:00.0: DRM: wndw-2: timeout
04:50 imirkin: that's bad
04:50 imirkin: that probably accounts for the weirdness too
04:50 imirkin: something's not being programmed correctly
04:50 lovesegfault: imirkin: What does that msg mean?
04:51 imirkin: i mean, i could try to explain, but long story short "shit's messed up, yo!"
04:51 lovesegfault: :D
04:51 imirkin: kelleymcches: i think that turing has had some updates since 5.4
04:51 imirkin: i'd give 5.5 or 5.6 a shot
04:52 kelleymcches: turing?
04:52 kelleymcches: which package is that?
04:52 imirkin: it's your GPU
04:52 lovesegfault: kelleymcches: are you using ~x86_64 keyworded on Gentoo?
04:52 lovesegfault: kelleymcches: it's the GPU family
04:52 imirkin: it's in the "Turing" family
04:52 kelleymcches: ah
04:52 imirkin: nouveau kernel driver has had some updates for turing-family gpu's since 5.4
04:52 lovesegfault: Maxwell -> Turing -> Pascal -> Volta (I think)
04:52 imirkin: no
04:52 imirkin: turing is at the end
04:52 imirkin: it's the latest
04:53 lovesegfault: Oh, I see
04:53 kelleymcches: i can try the experimental kernel that gentoo supplies and see if that works
04:53 lovesegfault: kelleymcches: experimental? Is 5.6 not yet ~x86 keyworded?
04:53 lovesegfault:goes look
04:54 lovesegfault: https://packages.gentoo.org/packages/sys-kernel/gentoo-sources
04:54 lovesegfault: 5.6.4 is keyworded,
04:54 lovesegfault: you can just use it
04:54 lovesegfault: the `experimental` USE flag is just for enabling building with SIMD optimizations IIRC
04:54 imirkin: i think these two commits:
04:54 imirkin: https://github.com/skeggsb/nouveau/commit/0764baeeb737771e71b204630fca57f6bd3974e4
04:54 imirkin: https://github.com/skeggsb/nouveau/commit/e259bf65680933c80e25231b7a09223a68b11029
04:54 imirkin: are likely to help your situation
04:56 imirkin: kelleymcches: those should be in v5.6.
04:56 imirkin: anyways, i'm off. good luck!
04:56 lovesegfault: imirkin: o/
04:58 kelleymcches: imirkin: thanks for the help!
04:59 kelleymcches: i'm just installing the newer kernel right now
05:10 kelleymcches: lovesegfault: alright so i'm on the 5.6.4 kernel and it seems that it's all good now
05:10 kelleymcches: i am seeing nouveau loading in dmesg and i'm not having that weird graphical glitch
05:11 lovesegfault: kelleymcches: awesome!
05:12 kelleymcches: lovesegfault: thanks for all the help!
05:12 lovesegfault: no worries, always happy to come across a Gentoo user :)
09:32 jbryn: Anyone good at decoding chipset ID's?
09:32 jbryn: MY FX 5200 has a chipset of B1004203...
12:40 karolherbst: imirkin: sadly it's not that simple :/
12:41 karolherbst: R4 <-> RGB4 is legal eg
12:41 karolherbst: ohh, but would cover that as well... mhh
12:50 karolherbst: but mhh
12:51 karolherbst: we have stupid shit like GL_RGB5 and GL_RGB565
13:00 karolherbst: I think it would be enough to be able to do a plain conversions from GL format to mesa format
13:13 imirkin: jbryn: FX 5200 = nv34
13:17 karolherbst: imirkin: adding _mesa_format_from_sized_format(GLenum) and then use _mesa_get_format_bits?
13:19 imirkin: karolherbst: yeah....... at that point, might as well implement _mesa_get_glformat_bits
13:19 imirkin: which is what you've done anyways
13:19 imirkin: it's also questionable what to do about e.g. RGB9_E5
13:19 karolherbst: well.. the idea would be to just reuse whatever we have for the mesa format stuff
13:19 imirkin: you have it listed as 9,9,9,5, but that's not right :)
13:20 karolherbst: mhhh
13:20 karolherbst: true
13:20 imirkin: it's 3 floats, which share an exponent
13:20 karolherbst: wellllll
13:20 imirkin: it's probably in a class of its own
13:20 karolherbst: it's still 3*9+5 bits, no? :p
13:20 imirkin: yes
13:20 imirkin: but it doesn't have 5 bits of alpha
13:20 karolherbst: but yeah..
13:21 karolherbst: never said the 4th value has to be the bits of the alpha channel :p
13:21 karolherbst: mhh
13:21 karolherbst: maybe I should handle the exponent case a bit better
13:23 imirkin: you could also define copyable classes of formats
13:23 imirkin: sort of like views
13:23 imirkin: but more like by component size
13:23 karolherbst: mhhh
13:23 imirkin: and then just have glformat -> class
13:24 karolherbst: dunno...
13:24 karolherbst: I know there aren't such "strange" formats, but R4B8 would be compatible with R4 and B8
13:25 imirkin: lol
13:25 imirkin: there's L8A8
13:25 imirkin: oh, but not in ES
13:25 karolherbst: :)
13:27 karolherbst: but mhh
13:28 karolherbst: now that I've already done the work for this table... I don't think doing a different solution requring similiar time makes that much sense
13:28 karolherbst: and adding new entries is already trivial
13:32 karolherbst: okay.. so the GLES spec knows RGBAS components
13:32 karolherbst: S being shared
13:32 karolherbst: might as well change my stuff to reflect this better
13:43 imirkin: karolherbst: yeah, fine by me
13:44 imirkin: i didn't realize that RGBA8 -> RGB8 is ok
13:44 karolherbst: yeah...
13:44 karolherbst: only components existing in both formats are considered
13:44 karolherbst: something like R4 -> G32 would also be oka
13:44 karolherbst: y
13:46 karolherbst: orr.. maybe not
13:46 karolherbst: seems like you can't add new components, but you can remove some.. okay
13:47 imirkin: then my class thing is totally inappropriate anyways
13:47 imirkin: and your thing is basically the only solution
13:47 imirkin: or a diff implementation of the same thing. be prepared for someone to ask for a csv.
13:47 karolherbst: "For example, an RGB color buffer can be used to create LUMINANCE or RGB textures, but not ALPHA, LUMINANCE_ALPHA, or RGBA textures. Table 8.13 summarizes the valid framebuffer and texture base internal format combinations." :)
13:48 karolherbst: the spec is a bit hard to read in this ready :/
13:48 karolherbst: *this area
13:48 karolherbst:
13:50 karolherbst: LUMINANCE == RED btw.. didn't know that
13:51 imirkin: oh right, ES2 *does* have alpha/luma
13:51 imirkin: but not intensity?
13:52 imirkin: (intensity is a single value replicated across all chans, luminance is only rgb)
13:54 karolherbst: fun part here is, that the spec quote doesn't exist in 3.2 :/
13:54 imirkin: luminance/alpha are deprecated post-ES2
13:57 karolherbst: ahh
13:57 karolherbst: they moved the error description
13:58 karolherbst: "An INVALID_OPERATION error is generated if the component sizes of internalformat do not exactly match the corresponding component sizes of the source buffer’s effective internal format."
15:59 lovesegfault: imirkin: my DP monitor (connected over USBC) now only works if I:
15:59 lovesegfault: 1. plug in
15:59 lovesegfault: 2. wait for it to detect a connection (it shows a message, takes like 2s)
15:59 lovesegfault: 3. run lspci
16:00 lovesegfault: If I don't do lspci the monitor doesn't work
16:00 lovesegfault: 😄
16:00 imirkin: lovesegfault: lspci probably means "GPU off"
16:00 karolherbst: heh..
16:00 imirkin: since lspci will wake up the GPU
16:00 orly_owl: unique bug
16:00 karolherbst: so the ACPI hotpluf notification doens't work probably
16:00 karolherbst: *hotplug
16:01 karolherbst: Lyude might know more
16:01 imirkin: karolherbst: or the USB-C plug-in works somewhat differently
16:01 karolherbst: maybe
16:01 lovesegfault: https://gist.github.com/af2f94ae49a6a2df805e7639051db602
16:01 imirkin: anyways, this is far far far outside my knowledge area.
16:01 lovesegfault: look at the bottom
16:01 imirkin: i still have a Riva TNT2 plugged in
16:01 imirkin: so...
16:02 karolherbst: "pcieport 0000:00:1b.4: PME: Spurious native interrupt!" heh
16:03 Lyude: lovesegfault: can you grab a log with "log_buf_len=50m drm.debug=0x6" added to your kernel boot params when it fails to detect the connector?
16:03 Lyude: Sorry, meant to say dmesg log (and the whole thing too)
16:03 lovesegfault: Lyude: most definitely I can; let me add those and reboot; one moment
16:03 Lyude: ka
16:04 Lyude: lovesegfault: actually
16:04 Lyude: Make drm.debug=0x16
16:05 lovesegfault:changes it
16:05 Lyude: (sorry for the slow typing-on my phone ATM, will be at a laptop shortly)
16:05 imirkin: Lyude: long commute to work? :p
16:05 Lyude: imirkin: nah, time has just lost all meaning since the quarantine started :P
16:06 imirkin: heh
16:06 imirkin: all that traffic from bedroom to living room... how can one survive it...
16:07 lovesegfault: my hair has gotten so long since this quarantine I have to use hair ties now
16:07 lovesegfault: I hate it
16:08 imirkin:is losing his
16:08 lovesegfault: alright, power cycling
16:10 lovesegfault: Lyude: https://gist.github.com/473cd0413e84886d2d4cbab6938cbf98
16:11 lovesegfault: I booted with the cable unplugged; plugged it in once I was in sway, opened a term and did lspci to make it work
16:13 lovesegfault: This one has more logs from when I started using the system, a bunch of DRM: base-3 cleanup; https://gist.github.com/b5fb28898a7a57753d016100b0e11c6b
16:18 Lyude:looks
16:20 Lyude: lovesegfault: what kind of a system is this by the way?
16:21 lovesegfault: Lyude: It's a Thinkpad P1, with a Quadro P2000
16:21 lovesegfault: Running NixOS/Sway
16:21 Lyude: lovesegfault: is that first or second gen?
16:22 lovesegfault: First gen
16:22 lovesegfault: Lyude: https://gist.github.com/2c0ab70e42dbb3ecdb99abbf2a7ab513
16:29 Lyude: lovesegfault: hm, I'm wondering if maybe we need ucsi working with nouveau for that machine to get hotplugs while the GPU is suspended
16:29 Lyude:is looking through the ucsi driver right now
16:31 imirkin: fwiw under normal circumstances, plugging something into a sleeping GPU causes an ACPI notification which tells nouveau to wake up the gpu and see what's up
16:32 karolherbst: mhhh, it would make sense if it's somewhat different with USB though
16:32 imirkin: right.
16:32 karolherbst: Lyude: did you ever tested this hotplugging stuff with USB-C connectors?
16:32 karolherbst: (has a USB-C dock with HDMI here)
16:32 Lyude: karolherbst: to be honest I'm not sure if I did
16:32 Lyude: not with nouveau at least
16:33 karolherbst: yeah...
16:33 karolherbst: for fun reason, intel gets picked up when I plug in my dock :)
16:33 Lyude: karolherbst: happen to have any machines with usb-c hooked up to the nv gpu?
16:33 karolherbst: I could test on the P1...
16:33 karolherbst: let me check
16:33 Lyude: karolherbst: if you do check the P1 make sure it's actually initializing it's connectors properly, it didn't seem like we were on the x1 extreme 2nd gen i've got here
16:38 lovesegfault: karolherbst: I used to have a USB-C thinkpad dock, with a monitor connected via DP to the dock; and that worked perfectly
16:39 lovesegfault: It's now that I got a USBC-DP cable straight to the monitor that this issue is surfacing
16:43 Lyude: lovesegfault: I have a good idea to try. https://paste.centos.org/view/a29f5a4a can you turn on your machine without the usbc plugged, run that script, try hotplugging your usbc once (don't bother trying to get the monitor to turn on if it doesn't come on), then get me the output from that script?
16:44 Lyude: imirkin: also yeah-everything used to send hotplugs via acpi on laptops like this, but I wouldn't be surprised if the interface has changed for usb-c stuff
16:44 imirkin: right
16:45 karolherbst: ahh.. plasma under wayland is still annoyingly broken >D
16:45 imirkin: karolherbst: kwin got forked
16:45 karolherbst: Lyude: well.. everything works as expected
16:45 karolherbst: more or less
16:45 karolherbst: imirkin: it's not kwin which is broken
16:45 Lyude: karolherbst: interesting
16:45 karolherbst: kwin works fine
16:45 imirkin: o
16:45 lovesegfault: Lyude: On it, rebooting to test
16:45 karolherbst: it's everything else
16:45 imirkin: lol
16:45 karolherbst: imirkin: plasmashell crashes when I change anything display related
16:45 imirkin: cool
16:45 karolherbst: plugging in a new display -> plasmashell crashes
16:45 karolherbst: :D
16:45 karolherbst: well
16:45 karolherbst: at least it recovers
16:45 imirkin: that'll teach you!
16:46 linkmauve: karolherbst, isn’t it kwin which is responsible for that?
16:46 karolherbst: Lyude: anyway.. there is some issue I found where we don't recognize a display getting disconnected
16:46 karolherbst: _but_
16:46 Lyude: karolherbst: while the gpu is off you mean?
16:46 karolherbst: it also happens with intel...
16:46 karolherbst: _disconnected_ ;)
16:47 karolherbst: so..
16:47 Lyude: karolherbst: yeah-but i mean when does the disconnection happen
16:47 karolherbst: we think there is still a display, even though I pulled the plug
16:47 karolherbst: uhmmm
16:47 karolherbst: when I replug it in a different port
16:47 Lyude: because i know a lot of laptops don't send dc events while the secondary gpu is suspended
16:47 karolherbst: no, I mean
16:48 karolherbst: ohh wait.. intel doesn't have connects, it's probably a nouveau issue
16:48 karolherbst: Lyude: that's not what I meant
16:48 karolherbst: so, you have your display connected and everything works fine
16:48 karolherbst: nice extended desktop
16:48 karolherbst: now you decide to disconnect it
16:48 karolherbst: but.. your laptop still thinks the display is there ;)
16:48 lovesegfault: Lyude: it did not at all go as expected, lol
16:48 lovesegfault: ./test.sh: line 3: cd: /sys/kernel/debug/tracing: Not a directory
16:48 lovesegfault: ./test.sh: line 4: events/ucsi/enable: No such file or directory
16:49 Lyude: oh oops, i should have tested the script first lol
16:49 Lyude: one se
16:49 karolherbst: lovesegfault: probably need debugfs mounted
16:49 Lyude: oh yeah the script does work, you need debugfs mounted there then and tracing enabled in your kernel
16:49 lovesegfault: Oh, no, I just need sudo
16:49 karolherbst: or that
16:49 lovesegfault: As root I can see stuff in there
16:50 lovesegfault: Lyude: https://gist.github.com/5211186b96b64aede07f387349cfc342
16:50 Lyude: bingo :)
16:51 Lyude: lovesegfault: looks like we need to hook up ucsi in nouveau to make your machine work correctly then
16:51 lovesegfault: This one is with some more hotplugs https://gist.github.com/d8dda43cd4c37e206cd117c4cefcadae
16:52 lovesegfault: Not sure what UCSI is but that all sounds right to me :P
16:52 Lyude: lovesegfault: UCSI == usb-C software interface
16:52 Lyude: I -think- it is just the acpi interface for usb-c stuff
16:53 lovesegfault: Ah, that makes sense
16:53 Lyude: karolherbst: might be worth running my script up there on your laptop as well to see what hapens
16:53 Lyude: *happens
16:53 karolherbst: Lyude: even it's not USB-C related?
16:53 lovesegfault: karolherbst: Do you have a USB-DP cable too?
16:53 Lyude: karolherbst: oh-no, just the usb-c ports
16:53 karolherbst: :p
16:53 karolherbst: it happens with the native HDMI port
16:53 Lyude: ahhhh, wonder if it's going through some nvidia equivalent of an lspcon or something
16:54 karolherbst: no clue...
16:54 Lyude: karolherbst: does it report the connector as HDMI on nouveau or DP?
16:54 karolherbst: HDMI
16:55 lovesegfault: Wait, the native HDMI port works fine for me
16:55 lovesegfault: Well, it correctly powers on the GPU, etc
16:55 Lyude: lovesegfault: I've got a second gen P1 here, I'm going to start it up and see if I can reproduce any ucsi events on it. if so then I can use that machine to start adding support for this (but I'd also like to know if skeggsb has gotten to this yet)
16:55 lovesegfault: HDMI 2.0 is a mixed bag
16:55 imirkin: yeah, that's my bad =/
16:55 imirkin: fwiw i looked over the documented volta/turing display registers
16:56 imirkin: and they seem to match gm200/pascal for this bit of it
16:56 imirkin: but i didn't see anything wrong in what i was doing
16:56 imirkin: but also reg names != full programming guide
16:56 lovesegfault: Lyude: Let me know if there's anything I can do to test; patches, debugging, etc :)
16:56 Lyude: lovesegfault: np, are you usually hanging around in #nouveau?
16:56 Lyude: I can poke you when I have something to test
16:56 lovesegfault: Lyude: Yep, I'm always here and I have a bouncer
16:57 lovesegfault: I am also quarantined so I'm _ALWAYS_ around now
16:57 Lyude: lovesegfault: cool, I'll throw your name in my notes then and get back to you :)
16:57 Lyude: hehehe, yeah I feel that
16:58 lovesegfault: imirkin: The types of bug I see with HDMI 2 really make me feel like it's some timing thing
16:58 lovesegfault: Not sure how to justify that position, I just... feel the time issues
16:59 imirkin: i mean, i think that's probably right
16:59 lovesegfault: The quarantine has put my mind in tune with my HDMI issues
16:59 imirkin: but what should come before what -- dunno
16:59 imirkin: and my current physical setup makes it difficult to test anything in the first place
17:00 imirkin: (anything HDMI2-related that is)
17:00 lovesegfault: imirkin: Oh, because your TV is the only HDMI 2 device, right?
17:03 jbryn: <imirkin>jbryn: FX 5200 = nv34
17:03 jbryn: Yes... but...
17:03 jbryn: I'm not talking about model per se.
17:03 jbryn: I'm talking about the chipset ID, does it decode into a valid NV34 chipset ID?
17:04 jbryn: Or maybe, some sort of big endian bug (on Sparc64! :V) is causing the chipset ID to f#$! up...
17:26 imirkin: jbryn: dunno what you mean by chipset id
17:26 imirkin: jbryn: sparc64 should, generally, work. however iirc it has 8kb pages?
17:27 imirkin: which likely won't work too great with nouveau
17:27 jbryn: "Unknown chipset: B1004203"
17:28 imirkin: ah yeah, that's probably backwards. let's see....
17:28 imirkin: ~/src/envytools/rnn/lookup -a 34 0 034200b1
17:28 imirkin: PMC.ID => { STEPPING = 0xb1 | DEVICE_ID = 0x2 | CHIPSET = NV34 | FOUNDRY = TSMC }
17:29 imirkin: generically, BE should work
17:29 imirkin: however my G5's psu died
17:29 imirkin: jbryn: if you're a developer, i could probably guide you through what needs to be looked into to see why the BE detection isn't working
17:30 imirkin: if you're not, stick with offb :)
17:33 jbryn: Debugging a NetBSD issue with another developer.
17:35 imirkin: ok
17:35 imirkin: so basically, all nvidia GPUs are LE devices
17:35 imirkin: however
17:35 imirkin: they have some bits built into them to make themselves appear a bit more BE-friendly
17:36 imirkin: one such bit is the "flip mmio accesses" bit
17:36 imirkin: if you're seeing the boot0 the way you are, that means it's not flipped.
17:36 karolherbst: imirkin: we never check that it succeeds though
17:36 karolherbst: and our check is a bit broken to be honest
17:36 imirkin: chekc for what?
17:36 karolherbst: endianess
17:36 imirkin: should be reliable.
17:37 karolherbst: "should", but isn't
17:37 Lyude: karolherbst: jfyi I am seeing [ 327.174687] nouveau 0000:01:00.0: fifo: fault 00 [VIRT_READ] at 00000000000bd000 engine c0 [BAR2] client 07 [HUB/HOST_CPU] reason 0d [REGION_VIOLATION] on channel -1 [00ffedf000 unknown] ← with runpm working w/ your patch on this P1, although rpm seems to still work fine anyway
17:37 karolherbst: I know that it doens't work on newer gens
17:37 Lyude: seems to happen on runtime suspend
17:37 imirkin: karolherbst: not surprised.
17:37 karolherbst: but new means "turing" here :p
17:37 imirkin: karolherbst: but this is nv34, so should work
17:37 karolherbst: still..
17:37 karolherbst: what we do is to check wheather a full reg is 0 or not
17:38 karolherbst: and if there are other random bits...
17:38 imirkin: don't confuse the issue...
17:38 karolherbst: anyway, it might be fine
17:38 imirkin: jbryn: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/device/base.c#L2970
17:38 karolherbst: I just see potential for screw up there
17:38 imirkin: i expect this is done differently in netbsd
17:38 imirkin: perhaps you can point me at the code there
17:39 Lyude: lovesegfault: jfyi, I realized I forgot to ask one thing: did you make sure the firmware on that machine is up to date?
17:39 imirkin: karolherbst: it should work as is. please don't bring up hypothetical issues for someone trying to debug a should-be-supported case.
17:39 jbryn: https://github.com/NetBSD/src/blob/trunk/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/device/nouveau_nvkm_engine_device_base.c#L2405
17:39 imirkin: well, that looks PRETTY similar...
17:40 karolherbst: I guess __BIG_ENDIAN might be not valid for NetBSD
17:40 karolherbst: mght need a different check?
17:40 imirkin: jbryn: what's the stuff above?
17:40 imirkin: it does it twice!
17:41 imirkin: oh, i see. #if NETBSD
17:41 imirkin: jbryn: ok, so that code isn't equivalent
17:41 imirkin: jbryn: the netbsd code compares != 0 and != 1
17:42 imirkin: but it should compare != 0 and == 0
17:42 imirkin: see line 2389
17:43 imirkin: jbryn: also please confirm that __BIG_ENDIAN ends up being defined
17:43 karolherbst: seems like that code usually does things like __BYTE_ORDER == __BIG_ENDIAN
17:43 karolherbst: but it also looks like that using __BIG_ENDIAN is actually fine
17:45 karolherbst: ... I actually have some patches in this area I should probably post at some point.. but it fixes a different issue
17:51 imirkin: karolherbst: ah yeah, i guess if boot1 contains vgpu bits, then it won't work. sounds like turing problems though :)
17:51 karolherbst: :)
17:52 imirkin: karolherbst: have you verified that the value read back is 0x01000001 in the "swapped" case?
17:52 karolherbst: but I also added detection if the endianess change actually does something
17:52 karolherbst: imirkin: no endianess support on turing
17:52 imirkin: karolherbst: ok, but you changed the logic
17:52 karolherbst: how so?
17:52 imirkin: went from checking != 0
17:53 imirkin: to checking that it's equal to a specific value
17:53 karolherbst: ahh mhh
17:53 karolherbst: good question actually
17:53 imirkin: iirc those are mirror bits, so it should be fine
17:53 karolherbst: I wasn't able to test that yet
17:53 imirkin: but i'm not 100% sure
17:53 karolherbst: yeah..
17:53 imirkin: easier to just leave it alone, probably
17:54 imirkin: i.e. keep the logic the same as it was
17:54 karolherbst: well..
17:54 karolherbst: would trigger on a vgpu
17:54 imirkin: coz it has one of those set?
17:54 karolherbst: the vgpu bit is in 0x4
17:54 imirkin: right
17:54 karolherbst: so if a bit it set...
17:54 imirkin: i mean do the AND mask
17:54 imirkin: but then check that it's != 0
17:54 karolherbst: yeah.. probably
17:54 imirkin: rather than == mask
17:54 karolherbst: ohhh
17:54 karolherbst: mhhh
17:54 karolherbst: yeah
17:54 karolherbst: good point
17:55 imirkin: jbryn: are you off testing, or did i completely confuse you?
17:57 jbryn: I'm testing.
17:58 imirkin: cool :)
18:00 jbryn: Still B1004203.
18:00 jbryn: :(
18:00 jbryn: Let's see if BIG_ENDIAN is actually defined...
18:12 karolherbst: would be nice to be able to do "return bool(boot1) != bool(__BIG_ENDIAN)"
18:16 lovesegfault: Lyude: Hey, sorry, my notifications aren't working
18:16 Lyude: lovesegfault: np
18:17 lovesegfault: It should be up to date; how can I verify that?
18:17 lovesegfault: nixpkgs is usually pretty bleeding edge
18:20 Lyude: lovesegfault: fwupdmgr
18:26 jbryn: Uh OH!
18:26 jbryn: __BIG_ENDIAN is not being defined!
18:26 lovesegfault: Lyude: Then yes, it's all up to date :)
18:26 jbryn:facepalms.
18:27 imirkin: jbryn: oops... that's a good one to do :)
18:27 imirkin: it's only used in like 2-3 places in the code
18:27 imirkin: but it's important
18:27 imirkin: feel free to replace it with something more netbsd-appropriate
18:28 Lyude: lovesegfault: alright-just making sure
18:28 lovesegfault: Lyude: of course :)
18:42 Lyude: lovesegfault: ok-while hotplugging isn't broken in the same way on this machine I'm able to receive ucsi events, so hopefully I should be able to use this to come up with some patches to support this
19:00 imirkin: jbryn: please note that the 3d accel has serious issues on big-endian ... anything using "fancy" features (which is all relative -- driver only advertises GL 1.5) will run into trouble
19:03 jbryn: glxgears isn't fancy... :)
19:03 imirkin: glxgears works
19:03 imirkin: (should work)
19:03 imirkin: but once you get into index buffers, vbo's, etc
19:04 imirkin: some things work, others don
19:04 imirkin: don't*
19:04 imirkin: stuff randomly gets byte-swapped, and i failed to identify all the right places
19:04 imirkin: and also some things need to not-byteswap, but they do
19:04 imirkin: and i don't know how to turn it off
19:05 lovesegfault: Lyude: Woohooo
19:06 karolherbst: imirkin: you don't have any machine accessible with big endian support, right? everything "broke down"?
19:06 imirkin: well, i just had one
19:06 imirkin: and its PSU appears to have died
19:06 karolherbst: mhhh
19:06 imirkin: i still have it - forgot to throw it out when i moved
19:06 imirkin: it's a G5, apparnetly PSU problems were moderately common
19:06 karolherbst: how is that big endian stuff on arm working btw?
19:06 karolherbst: I saw some kernel option to flip it
19:06 imirkin: armbe is theoretically a thing
19:07 imirkin: but most boards don't support it
19:07 karolherbst: yeah...
19:07 karolherbst: I could try that out though..
19:08 imirkin: i think the cpu has to be configured for it
19:08 imirkin: it's not a software switch you flip at runtime
19:08 karolherbst: mhh the tk1 had a bi endian cpu at least...
19:08 jbryn: If you want to do some BE testing on this I could... the version of this nouveau is from 4.14 though, I'll gladly allocate some space for Debian to use a more recent one.
19:08 RSpliet: Heh, TIL big-endian RISC-V is a thing
19:08 karolherbst: jbryn: I am just wondering what boot1 looks like
19:08 karolherbst: meaning.. what's the value of boot1 after flipping it
19:08 imirkin: hmmm ... a few G5's on craigslist...
19:09 RSpliet: If only those new RISC-V falcon cores had a PCI-E port to plug an NVIDIA GPU into
19:09 jbryn: I was talking to imirkin.
19:10 imirkin: jbryn: not a ton of updates to nv34 support :)
19:10 imirkin: jbryn: tbh, i don't have time
19:10 imirkin: if there's a specific bug, i could look into it
19:10 jbryn: Let me know if you ever do have this "time..."
19:11 imirkin: (and the craigslist ad turns out to be far away)
19:12 imirkin: and the other one is even further away
19:13 imirkin: and some crazy people trying to sell a iMac G5 all-in-one for $200
19:13 imirkin: jbryn: anyways, will let you know, but don't count on it.
19:14 imirkin: jbryn: but if you do run into issues, feel free to let me know. this stuff should all work just as well (poorly) on netbsd as it does on linux
19:14 imirkin: esp once __BIG_ENDIAN is defined :p
19:18 linkmauve: karolherbst, I haven’t found a single Linux distribution compiled for AArch64 big-endian. :/
19:19 linkmauve: Unlike on ARMv7 and below, an userland application can’t switch endianness at will anymore, the kernel only has access to an instruction to do so.
19:19 karolherbst: linkmauve: yeah.. maybe because the kernel option just landed..
19:19 linkmauve: From what I’ve heard (probably from HdkR).
19:19 linkmauve: It just landed? :x
19:19 karolherbst: I think it came into 5.5 or 5.6
19:19 linkmauve: Woah!
19:19 karolherbst: or.. maybe that was something else :)
19:19 karolherbst: I saw something new though
19:22 karolherbst: mhhh
19:22 karolherbst: seems like it's there a bit longer
19:22 karolherbst: but mhh
19:25 karolherbst: ohh.. yeah, it was something else
19:25 karolherbst: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/Kconfig?id=d8e85e144bbe1
19:25 karolherbst: just made it prompt for me
19:26 karolherbst: but the reason nobody uses it is state right there: no ACPI support
19:26 karolherbst: and at that point it becomes pointless for a distribution to care
19:28 linkmauve: There are many platforms with no ACPI whatsoever.
19:28 linkmauve: I’d even say most.
19:29 karolherbst: that might be true, but distributions still kind of depends on something which doesn't force them to use dts files
19:31 karolherbst: eg for arm you kind of need SBSA
19:31 karolherbst: and this includes ACPI as well
19:32 karolherbst: so.. even if you have a distribution built against ARM, as long as that system doesn't support SBSA you are out of luck or need to put in some work to get the dtb stuff worked out
19:33 karolherbst: and let's face it, distribution won't generate device specific images except for a handful of exceptions
19:36 linkmauve: What is SBSA?
19:36 imirkin: acpi for arm
19:36 linkmauve: Ok.
19:36 imirkin: (sorta)
19:36 linkmauve: The stuff that is usually put in dtb?
19:36 karolherbst: yeah.. it also mandates UEFI support
19:37 karolherbst: linkmauve: it's more like a standard for firmware features
19:37 linkmauve: Uh, I don’t think I’ve ever seen an UEFI ARM board.
19:37 karolherbst: SBSA mandates ACPI and UEFI support
19:37 imirkin: linkmauve: arm laptops tend to be
19:37 karolherbst: it's de factor required for arm servers
19:37 karolherbst: *de facto
19:37 imirkin: yeah, and that
19:37 linkmauve: Ok.
19:37 imirkin: not for SBC's so much
19:37 karolherbst: makes it way easier
19:37 linkmauve: Yeah, I’ve mostly only worked on SBCs.
19:37 karolherbst: one image for all arm servers :)
19:38 linkmauve: Usually also a single image works on many of them, with /boot filled with random dtb files.
19:38 karolherbst: yeah..
19:38 linkmauve: % ls /boot/dtbs | wc -l
19:38 karolherbst: but then you still depend on the bootloader being able to pick the right one
19:38 imirkin: assuming you don't have to do appended dtb boot :)
19:38 linkmauve: 717
19:38 karolherbst: or not?
19:39 linkmauve: karolherbst, I guess so.
19:39 karolherbst: on the jetson nano I have to specify the dtb file in the bootloader config :/
19:39 karolherbst: it uses uboot though, so..
19:39 karolherbst: not that bad
19:39 imirkin: the fastboot ones need appended dtb afaik
19:39 imirkin: which is a lot of them
19:39 karolherbst: the problem is just, the kernel has to provide those files
19:39 karolherbst: or something else
19:39 karolherbst: and they need to be maintained, etc..
19:40 karolherbst: way easier to just ask the firmware imho
19:40 karolherbst: fun fact, firmware even have dtb files... just sometimes they are not compatible with the kernel
19:40 karolherbst: even the jetson has
19:43 Lyude: Can whoever's in charge of the nouveau ml let the message I just sent come onto the ml?
19:44 Lyude: it's stuck currently waiting for moderator approval
19:47 imirkin: i don't think anyone here has mod access
19:47 imirkin: which is ... silly
19:48 imirkin: Lyude: for your next iteration... vblank work*er*s
19:50 Lyude: imirkin: that's intentional actually, since we have a struct called kthread_worker and we want to differentiate between the thread executing the work and the work itself
19:50 imirkin: ok :)
19:50 imirkin: maybe work items then
19:50 imirkin: or leave it
19:50 karolherbst: can we get rid of scons please? :D
19:51 imirkin: no
19:51 imirkin: but you can feel free to break the scons build
19:51 karolherbst: the CI won't let me
19:51 imirkin: there was a discussion about it recently
19:51 imirkin: get the vmware guy to help you then
19:51 imirkin: jrfonseca mabye?
19:51 imirkin: going by memory
19:52 karolherbst: I tried to fix it myself.. let's see how that goes
19:52 karolherbst: but I needed to write up the code generation :/
19:52 karolherbst: maybe I got lucky
19:53 Lyude: karolherbst: do we allow building mesa with scons? ._.
19:53 karolherbst: for windows
19:53 Lyude: man fuck windows
19:54 imirkin: =]
19:54 karolherbst: aparantly some run windows vms for stupid reasons
19:54 Lyude: actually though-I'm a little surprised by that? meson works fine on windows
19:54 karolherbst: now that windows ported all their software to linux, no reason for win vms anymore :p
19:54 imirkin: Lyude: in theory, sure
19:54 imirkin: in practice, scons is the thing
19:54 Lyude: imirkin: i mean-meson's got ci setup for windows, i'd kinda hope we use that as an excuse to make it work there too
19:54 imirkin: yeah, that was the argument being used to request removal of scons
19:54 karolherbst: Lyude: send an MR to nuke it :p will probably trigger a fun discussion
19:54 Lyude: it is usually easier to fix meson then to not use meson in my experience :)
19:55 Lyude: ah
19:55 imirkin: but the practice is that meson also has a ton of dependencies
19:55 imirkin: like py3
19:55 karolherbst: well.. scons is py as well
19:55 Lyude: ^^
19:55 imirkin: and it screws up vmware's build
19:55 karolherbst: and we need py anyway
19:55 imirkin: [i know]
19:55 karolherbst: :p
19:55 imirkin: their basic argument is just leave scons alone
19:55 imirkin: and let them deal with it when they have to
19:55 karolherbst: okay
19:56 imirkin: instead of making them do a ton of work to try to get meson to work, which they've tried and didn't quickly succeed at
19:56 karolherbst: ohh that's why the fail is only a warning btw..
19:56 karolherbst: oh well
19:56 imirkin: Lyude: iirc there were llvm-related complications too
19:56 imirkin: it's all covered on the mesa-dev thread
19:57 RSpliet: karolherbst: my reason for running Windows (in a VM) every now and again is to interface with my car's diagnostics. It's arguably a bad reason, but not one I can work around sadly :-(
19:57 karolherbst: wine?
19:57 Lyude: karolherbst: no drinking and driving
19:57 RSpliet: Ofc that's not a reason for needing scons :-D
19:58 karolherbst: :p
19:58 karolherbst: but I'd assume that stuff would just work under wine though
19:58 karolherbst: that little networking stuff
19:59 RSpliet: The USB-to-not-quite-ODBII controller is the big issue there
19:59 imirkin: i had to fix something in the SSL impl to get wine to work with XenCenter
19:59 karolherbst: uhhhh
19:59 karolherbst: why do you have to bring up the worst parts of computes :/
19:59 RSpliet: Because we're talking Windows
20:00 karolherbst: there are still different kind of badness in windows
20:00 karolherbst: super bad is: citrix, stupid "hw tools" and then "not so bad" is everything else :p
20:00 RSpliet: Wait 'til you hear what OS most OEM car software requires
20:00 imirkin: well, i wasn't going to get into it, but XCP-ng Center :)
20:01 imirkin: RSpliet: winxp?
20:01 RSpliet: yep
20:01 karolherbst: last time I used citrix stuff it looked like software escaping a compute museam
20:01 karolherbst: *museum
20:01 imirkin: karolherbst: well, xen didn't start out as a citrix thing :)
20:01 imirkin: anyways, the xen center is just an application to manage the cluster
20:01 RSpliet: Funny you say... I was in a computer museum last year. You won't believe what tried to escape...
20:01 imirkin: it's ... fine.
20:02 imirkin: RSpliet: they let you out :p
20:02 karolherbst: I refuse to accept anything citrix is doing is "... fine", not even that I accept :p
20:02 imirkin: anyways, xcp-ng is the fully open effort
20:03 RSpliet: It was me or NetViewer
20:03 karolherbst: :D
20:03 imirkin: have you been to the one in mountain view?
20:03 imirkin: i was there when they still had the babbage machine
20:04 RSpliet: ah no I only went to the one in Cambridge
20:04 karolherbst: ahh.. I should have gone there :/
20:04 karolherbst: I actually was in mountain view once
20:04 RSpliet: although the Computer Lab has more impressive pieces of hardware
20:04 RSpliet: I think they have the EDSAC out at the moment
20:04 imirkin: the fact that babbage's difference engine actually works is nuts
20:05 imirkin: and also the reason why he wanted to build it in the first place is hilarious (look it up)
20:06 imirkin: "in order to solve this simple problem, i am going to invent programmable computers"
20:07 RSpliet: Quite the visionary
20:16 imirkin: jbryn: actually there were a handful of (kernel) patches i was hoping to test on a BE setup ... could i send you stuff? it'
20:17 imirkin: it'd basically be "boot this, run this program, see if the colors are all fooey"
20:18 imirkin: (i don't have the patches now, but would not be too difficult to write them if i had a tester)
20:22 AndrewR: hi all. I tried to run Audiosurf2 on nouveau (via wine 5.5). some modesk and skins works, but at least one - not. I see GLSL link errors. For example: https://pastebin.com/Gjz6wwqZ I think it may work if I replace ps_in[14].x = shader_in.reg14.x; with in.reg13.x , but who generates them, wine ?
20:47 AndrewR: https://source.winehq.org/git/wine.git/blob/refs/tags/wine-5.6:/dlls/wined3d/glsl_shader.c - i think it set here .... (sorry for wine-related thing, just was surprized how it worked on LLVMpipe and not on nv50-class GPU (nv92))
20:48 jbryn: <imirkin>jbryn: actually there were a handful of (kernel) patches i was hoping to test on a BE setup ... could i send you stuff? it'
20:48 jbryn: Sure.
20:54 imirkin: jbryn: awesome, thanks
20:55 imirkin: AndrewR: i'm surprised that it would work with llvmpipe
20:55 imirkin: that sort of stuff is checked by the core
20:55 imirkin: i expect that wine takes an alternate path in that case
20:56 AndrewR: imirkin, may be llvmpipe enables idfferent path in wine ..I saw transformfeedback3 and few other extensions from it
20:56 imirkin: AndrewR: oh, i expect it's because llmvpipe supports more frag shader inputs.
20:57 AndrewR: imirkin, are those limits visible with glxinfo -l ?
20:57 imirkin: yes
20:57 imirkin: although it should be able to support 14 vec4's + gl_FragCoord just fine
20:57 imirkin: er, 15 vec4's
20:57 imirkin: maybe not for some reason?
20:58 AndrewR: GL_MAX_FRAGMENT_INPUT_COMPONENTS = 128 for llvmpipe , GL_MAX_FRAGMENT_INPUT_COMPONENTS = 60 for hw
20:59 imirkin: right
20:59 imirkin: that should be 64.
21:01 AndrewR: also GL_MAX_FRAGMENT_UNIFORM_BLOCKS = 15 for sw, and GL_MAX_FRAGMENT_UNIFORM_BLOCKS = 13 for hw ...
21:02 AndrewR: imirkin, does this mean my hw will not run it, but say something like nvc0/r600 will (with same wine setup) ? (My friend who created mod has rx480, or something like this - radeonsi with mesa)
21:05 Lyude: (sorry for the nv email spam i'm about to send, needed to make some changes to the igt crc tests and I don't want v3 to not be on both igt-dev and nouveau's ml because that will just get confusing)
21:12 imirkin: AndrewR: i'll have to check what blob reports
21:12 imirkin: unfortunately the definition of these things can be very confusing
21:12 imirkin: i.e. what counts towards it and what doesn't
21:40 Lyude:completely forgot there was a ucsi driver by nvidia
21:41 imirkin: i keep reading that as uscsi
21:41 Lyude: fair
21:41 imirkin: and thinking "huh, user scsi, what for"
21:41 imirkin: "oh, must be scsi over usb"
21:41 imirkin: :)
21:42 Lyude: ah, cool, immediate lockdep warning with ucsi dp partner mode drivers enabled
21:42 imirkin: (that's a thing btw, "uas" iirc)
21:42 karolherbst: uhh :/ I also will boot into a debug kernel soon with all kind of stuff enabled...
21:42 karolherbst: I am sure everything will explode
21:43 karolherbst: Lyude: btw.. is the fedora debug kernel enough for kasan or will I need to compile it myself?
21:44 Lyude: karolherbst: you will need to compile it yourself, kasan would be too problematic to have on as a default like that for debug kernels
21:44 karolherbst: ahh :/
21:45 karolherbst: skeggsb wasn't able to reproduce the issue I have :/ and it's in the memory allocation code :(
21:45 Lyude: karolherbst: yikes, what issue is that exactly?
21:45 karolherbst: creating gem object fails randomly
21:46 Lyude: lovesegfault: you still around? just wondering if your system uses a default kernel or if you're building it yourself
21:46 karolherbst: Lyude: https://gist.github.com/karolherbst/56526072aa9b1947b6438540619fb7c0
21:46 Lyude: karolherbst: oh no that sounds painful
21:46 karolherbst: no idea why.. but if I resubmit the exact same ioctl, it succeeds :)
21:46 lovesegfault: Lyude: Hey, I use 5.6.4 with a couple patches
21:46 lovesegfault: one moment
21:46 karolherbst: Lyude: I just hope it's something super stupoid
21:47 karolherbst: and something kasan can detect
21:47 Lyude: lovesegfault: basically I'm wondering if you have all of the relevant usci stuff enabled in your kernel, wondering if enabling that might just make it 'work'
21:47 lovesegfault: Lyude: https://github.com/lovesegfault/nix-config/blob/master/hardware/nouveau.nix
21:47 Lyude: karolherbst: kasan is usually pretty good
21:47 karolherbst: people used to say that about valgrind :p
21:47 lovesegfault: How can I check if it's enabled?
21:48 Lyude: lovesegfault: i don't know anything about nix :P, and I guess: find /usr/lib/modules/$(uname -r) -name typec_\*.ko
21:50 Lyude: and let me know what that shows
21:55 lovesegfault:fidgets
22:00 lovesegfault: Lyude: https://gist.github.com/94060f562185c228aa3bf7674993308c
22:02 Lyude: lovesegfault: ok-yeah you should have those enabled
22:38 karolherbst: ehhh
22:40 AndrewR: imirkin, https://github.com/mgoodfel/SeaOfMemes/issues/2 ?
22:40 AndrewR: imirkin, I think just for test I can raise this limit in gallium driver and see what broke ....
22:41 karolherbst: AndrewR: you have a broken OpenGL driver there :p
22:42 AndrewR: karolherbst, well, but may be not in area where it reported limits ?
22:43 karolherbst: I mean.. Apple never really cared much about their OpenGL stack sadly
22:44 HdkR: woof, that's some real good broken driver right there
22:44 karolherbst: but mhhh, if this is about GL_MAX_FRAGMENT_UNIFORM_BLOCKS generally
22:45 jbryn: imirkin: DM :P
22:45 jbryn: PM*
22:46 karolherbst: actually, we could increase GL_MAX_FRAGMENT_UNIFORM_BLOCKS a bit on maxwell :D
22:46 karolherbst: or make it unlimited and spill the buffers
22:46 karolherbst: dunno
22:46 karolherbst: applications needing many ubos deserve low perf
22:47 HdkR: That's mean for the people expecting it to be a true UBO :P
22:47 karolherbst: yeah.. well
22:47 HdkR: Although even Nvidia doesn't give a flip about that considing the Compute UBO problems
22:47 karolherbst: we could report inifnity, I really don't care if applications are being stupid
22:47 HdkR: considering*
22:47 karolherbst: yeah, me neither
22:47 karolherbst: such limits gets pointless if driver report fake values
22:48 karolherbst: AndrewR: so if I got the right, you have an applications requiring tons of ubos and that doesn't work as well on your hw?
22:49 karolherbst: imirkin: I have an idea: we report what the hw can do, but if an application really asks for it, we just allow more ubos.. could we do that?
22:49 karolherbst: or would that violate the spec
22:49 HdkR: It would violate the spec allowing binding a UBO index larger than the max reported
22:49 HdkR: There is some sentence in the spec about it
22:49 AndrewR: karolherbst, I only tried wine, and with some custom level in audiosurf2 it failed shader compile ....
22:49 karolherbst: ehhh
22:50 karolherbst: wine doesn't care about limits
22:50 karolherbst: it just does stuff
22:50 karolherbst: but..
22:50 karolherbst: would be easy to handle that in wine I guess
22:50 karolherbst: with a bit of trickery
22:50 HdkR: I know of this sentence since a while back I was looking at using UBO indexes outside the range but still only binding less than max number per stage :/
22:50 karolherbst:really wants to rework our const buffer handling a little
22:51 karolherbst: but.. that would only help with maxwell+ :)
22:51 karolherbst: AndrewR: what GPU do you have? nv50 based?
22:52 karolherbst: imirkin: you wouldn't mind if I move the driver constbuf to 0, right?
22:53 AndrewR: karolherbst, OpenGL renderer string: NV92
22:53 karolherbst: mhh
22:54 karolherbst: "GL_INVALID_VALUE is generated if uniformBlockBinding is greater than or equal to the value of GL_MAX_UNIFORM_BUFFER_BINDINGS." ehh
22:54 karolherbst: HdkR: we just bind nonetheless...
22:54 karolherbst: :D
22:54 karolherbst: and just throw the error for fun
22:57 karolherbst: AndrewR: is this a dx11 application? I am wondering why wine would use ubos ...
22:57 karolherbst: or was it already there in d3d9, but I don't find the proper term :/
23:00 AndrewR: karolherbst, dx10
23:00 karolherbst: huh...
23:00 karolherbst: wait..
23:01 karolherbst: that first compile error you showed sounds like a wine or application bug
23:01 karolherbst: static OOB array access
23:02 karolherbst: if dx10 allows this crap, but GL doesn't then wine needs to fix that
23:02 karolherbst: but yeah
23:02 karolherbst: sounds like a wine bug :p
23:04 karolherbst: AndrewR: you could try to break on shader_glsl_declare_shader_inputs if element_count == 14 and see if that 14 was clamped or something
23:04 karolherbst: but ufff
23:04 karolherbst: just ask a wine dev to look into it :p
23:05 AndrewR: karolherbst, I already posted this to winehq channel
23:05 karolherbst: you probably want to create a bug though :/
23:06 karolherbst: ahhh
23:06 karolherbst: unsigned int in_count = min(vec4_varyings(version->major, gl_info), shader->limits->packed_input);
23:06 karolherbst: what's packed_input
23:07 jbryn: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv10.c
23:07 jbryn: Hm... does this code look big endian safe?
23:08 jbryn: From a glance there isn't a problem, but it appears to crash here on sparc64...
23:09 jbryn: I'll have to see what line it is.
23:09 jbryn: That's causing the crash*
23:11 AndrewR: imirkin, karolherbst - hacking case PIPE_SHADER_CAP_MAX_INPUTS to 32 allows custom skin to run (at least model is visible now ... and other objects )
23:11 karolherbst: heh
23:11 karolherbst: mhh
23:13 karolherbst: classic.. a variable which never gets assigned properly
23:13 karolherbst: argh
23:14 karolherbst: sometimes I really hate devs
23:15 karolherbst: ahhh shader_set_limits
23:16 karolherbst: okay.. heh
23:23 karolherbst: AndrewR: yeah.. from a quick glance I don't really know whos at fault here.. but probably wine
23:23 karolherbst: they tend to not care about unused inputs or outputs
23:23 karolherbst: and just declare everything
23:23 karolherbst: mhhh
23:26 karolherbst: AndrewR: do you know if there is a way to dump the hlsl shaders?
23:26 AndrewR: karolherbst, not yet ... (looking into google)
23:26 karolherbst: but yeah, it sounds more reasonable that it's an issue with shader inputs, not const buffers
23:33 karolherbst: ahh nice... bugs not shoing on debug kernels.. very nice
23:44 AndrewR: so it was set like this in 2013..? https://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau/nv50/nv50_screen.c?id=bad8871e524cf518bc5da4ac52c1618a115054a7
23:46 karolherbst: AndrewR: do you know what nvidia reports for that hw?
23:46 AndrewR: karolherbst, no ..:(
23:46 AndrewR: karolherbst, onle some glxinfo output from similar (?) hardware
23:46 karolherbst: I am all for increasing that numbers as long as we don't cause regressions :p
23:47 karolherbst: AndrewR: similiar is probably enough
23:48 AndrewR: karolherbst, https://compubench.com/device.jsp?benchmark=compu20&D=NVIDIA+GeForce+9600+GT&testgroup=info
23:49 AndrewR: karolherbst, I think re-running this piglit test or few more related to those limits will help? (I have piglit, but not compiled new version of it)
23:49 karolherbst: well.. we first need to figure out what nvidia exposes :p
23:49 karolherbst: no point reporting higher values if the hw is not capable
23:50 karolherbst: AndrewR: what does glxinfo report for GL_MAX_FRAGMENT_INPUT_COMPONENTS?
23:51 karolherbst: 60 or something else?
23:51 AndrewR: karolherbst, 60 before I hacked driver, 128 now
23:51 karolherbst: mhhhh
23:51 karolherbst: so nvidia reports 128 as well
23:52 karolherbst: imirkin: any idea if we could bump PIPE_SHADER_CAP_MAX_INPUTS for fps to 32? probably some work, but I guess it might make sense to look into it
23:52 karolherbst: I just don't have any tesla gpus here
23:52 karolherbst: seems like we would have to limit it to 16 for geometry shaders though