00:36 imirkin: karolherbst: building an updated VK-GL-CTS to see where the issues are... anholt was complaining about something pbo-related too
00:50 rhyskidd: Lyude: great timing that envytools has VBIOS PMU fuc support ... :)
00:51 rhyskidd: should at least help figure out what's going wrong with that HP bios
00:52 karolherbst: imirkin: it hits an gallium assert somewhere
00:52 karolherbst: afaik
00:52 imirkin: yeah, that's what anholt was seeing
00:52 imirkin: with a KHR-GLES3 test
00:52 imirkin: something in copytex
01:45 imirkin: ok, the KHR-GL45.packed_pixels.rectangle.rg32ui failure looks like a lack of truncation somewhere
01:45 imirkin: <Text>Integer comparison: 4, 0, 72: 127 == 4294967168: not equal.</Text>
01:45 imirkin: or, conversely, truncation when there shouldn't be
01:58 karolherbst: imirkin: I guess I may look into those things over the next few weeks
01:58 karolherbst: or at least I would like to
01:58 karolherbst: CTS is kind of my next big topic on my todo list :)
02:03 karolherbst: but first I need to figure out what is funky with my nir stuff and images. I don't get quite the image r references right if there is one array of images declaration in the shader
02:03 karolherbst: anyway, it is quite late here :(
03:05 imirkin: karolherbst: well, before you dive into any particular failure, check with me
03:05 imirkin: i pretty much know why each one happens
03:06 imirkin: (unless they're new ones, obviously)
04:14 orbea: could these GL errors shown by apitrace be another 3.1 GL context issue? https://pastebin.com/8uHDiDYw
04:41 orbea: guess RetroArch is not even using a core context itself...
04:41 orbea: a 1.0 compat context works :P
10:04 lachs0r: switched back to nvidia and the first thing it did was apparently stomping all over the memory of the xfs driver
10:04 lachs0r: scary
10:04 gnarface: yikes indeed
10:06 lachs0r: I also had to power down my machine again because the buggy nvidia GPU stalled as soon as I ran xorg afterwards
10:06 lachs0r: I am so sick of this bullshit
10:07 lachs0r: and I didn’t think the difference in responsiveness would be THAT obvious after using nouveau for a few days
10:07 lachs0r: everything seems slower with nvidia
10:07 lachs0r: feels like huge input lag
10:10 lachs0r: if this were my laptop I’d wonder if the intel cpu got stuck in powersave mode again
14:08 karolherbst: imirkin: mhh just noticed that image/sampler refs are 64 bit in TGSI
14:09 karolherbst: but I guess we will never get values above 32 bit?
14:09 imirkin: they're 64-bit in real-life too
14:09 imirkin: we're going to have to move to them being a VA and retrieving some params out of gmem, i think
14:10 karolherbst: mhh
14:10 karolherbst: can't we just read them out as a 64 bit uniform value?
14:10 imirkin: my current approach doesn't seem to account for a few things
14:10 imirkin: huh?
14:10 karolherbst: CONST[0][1].xyxy
14:10 karolherbst: this is what we get
14:11 imirkin: right...
14:11 karolherbst: ohh you mean in the instruction encoding?
14:11 imirkin: no...
14:11 imirkin: currently the handle is a TSC/TIC reference, which is 32-bit
14:12 karolherbst: ahh
14:12 imirkin: or a literal index
14:12 imirkin: which is much less than 32-bit
14:12 imirkin: (into a fixed-size array)
14:12 karolherbst: so it would be pointless to pass in 64 bit values
14:12 imirkin: in the future, however, we'll probably have to move to them being legit objects in gmem
14:12 imirkin: so 40 bits of it will matter
14:16 karolherbst: I see
14:16 karolherbst: we have bindless support in nir now, so I am kind of looking into all of this currently
14:18 karolherbst: it works more or less :(
14:19 karolherbst: works for images quite well, but the path I take is broken for samplers (radeonsi takes a different one)
14:22 imirkin: ah =/
14:22 karolherbst: well I just need to add a boolean flag to nir_tex_instr and set it. Will be a trivial change (+ nir_lower_sampler adjustemnts)
14:22 imirkin: well - setting tex->tex.bindless is very important for the whole thing to work ;)
14:22 karolherbst: :) yeah
14:22 karolherbst: but I don't get that info yet :)
14:23 karolherbst: I get basically a 0 for the sampler. No idea if it is bindless or not
14:24 karolherbst: something is wrong running tests/spec/arb_bindless_texture/execution/images/ubo-named-block.shader_test though
14:24 karolherbst: it does image stuff
14:24 karolherbst: but the image var doesn't get the bindless flag set
14:25 karolherbst: but mhh
14:25 karolherbst: imirkin: "writeonly image2D img;" inside a struct"
14:25 karolherbst: and that struct is used inside a uniform Block
14:30 karolherbst: uhh this looks so broken in nir
14:31 imirkin: if it's wrong in nir, you have little chance of getting it right in a nir -> nv50_ir conversion :)
14:33 karolherbst: yeah
14:34 karolherbst: stupid thing is, the test causes an engine fault :)
14:34 karolherbst: but.. I am thinking
14:35 karolherbst: sample index is the second src
14:36 karolherbst: but up until now it was always an undefined value I think
14:37 karolherbst: I guess the right apporach would be to put a load_uniform/load_ubo and set the second source to the results
16:16 imirkin_: hm i had an interesting idea. my problem was that i had nowhere to stick the layer
16:16 imirkin_: but ... i can just stick it into the handle!
16:16 imirkin_: and then always treat everything as a 2darray
17:34 karolherbst: imirkin_: uhh, there is a load_ubo, but it got DCEed away :(
20:46 Karut: Hi, i have this error in dmesg "DRM: failed to create encoder 1/8/0: -19" and i have video shuttering, is this somehow related?
20:47 imirkin_: no
20:50 Karut: then idk what else can i do.
20:51 imirkin_: you could describe your issue.
20:51 imirkin_: or you can get an AMD board
20:52 Karut: when i play a video every 2s the image freezes sightly.
20:52 Karut: happens with and without compositor
20:53 imirkin_: what kind of video, what gpu, what cpu
20:54 Karut: a youtube video, a video played in vlc and a video played inside a vm (all kinds of video), Nvidia 980ti, intel i7 4790K
20:54 imirkin_: full-screen, or windowed?
20:54 Karut: both
20:55 imirkin_: ok, so ... a few notes to consider
20:55 imirkin_: (a) no gpu-accelerated video decoding
20:55 imirkin_: (b) no gpu reclocking, so if you have a crazy resolution it'll probably be too slow
20:56 Karut: in firefox I've enabled hardware acceleration and tried with 240p and 4k videos. same issue.
21:03 imirkin_: i don't think you understood
21:03 imirkin_: there is no gpu-accelerated video decoding
21:03 imirkin_: without writing the code to enable such a thing, you aren't going to get it
21:03 imirkin_: and for a 4k video, that's both a lot of cpu
21:03 imirkin_: and a lot of things to draw on the screen
21:03 imirkin_: for a 240p video, that's more surprising
21:03 imirkin_: are you using a 4k resolution?
21:03 imirkin_: if so, can you use a smaller one?
21:05 Karut: I use a standard res on the monitor
21:06 imirkin_: the nice thing about standards is that there are so many to choose from
21:06 Karut: happens in 144p too
21:06 imirkin_: sounds like you're having some kind of vblank issues
21:06 imirkin_: do you see problems in regular desktop use?
21:07 Karut: no
21:07 imirkin_: hmmmmmmmmmmm
21:07 Karut: well...
21:07 imirkin_: i wonder if something's being dumb about tyring to do video-accelerated decoding
21:07 imirkin_: and then failing
21:07 imirkin_: and not handling that failure with quite the proper level of gracefulness
21:07 imirkin_: is this only youtube, or also e.g. mplayer?
21:07 Karut: I use a tiling wm, i can see that the mouse doesnt have this shuttering
21:07 imirkin_: what about moving windows around?
21:07 imirkin_: mouse is special
21:08 imirkin_: (it's a separate plane, and that plane gets moved around pretty easily)
21:10 Karut: I cant see problems in regular desktop use (tiling wms have pretty bad floating windows)
21:11 imirkin_: do you have mplayer or mpv?
21:11 imirkin_: also ... silly question ... do you have the firmware for acceleration?
21:12 Karut: imirkin_: letme download a video. Idk about the firmware xD
21:13 imirkin_: Karut: pastebin the output of 'dmesg'
21:15 Karut: yes, video on mplayer has shuttering too
21:16 imirkin_: ok cool
21:17 imirkin_: (well, not really cool, but ... heh)
21:17 imirkin_: that's a much more self-contained example than "youtube html5 player via browser is stuttering"
21:17 orbea: Karut: video freezes for a moment, but not sound?
21:17 imirkin_: my guess is that acceleration is off
21:17 imirkin_: and the whole thing is going via super-software paths
21:18 orbea: i been geting something like that in mpv, but worked aroudn with video-sync=display-resample
21:18 orbea: but its also compton related for me
21:18 imirkin_: well mplayer doesn't do any of that by default
21:19 imirkin_: should be using xv
21:19 orbea: yea, mplayer is unaffected for me
21:19 orbea: so maybe diffrerent
21:19 imirkin_: this could also be going in via xf86-video-modesetting
21:19 imirkin_: depending on the distro
21:20 Karut: imirkin_: https://pastebin.com/nNzbsskg
21:20 Karut: orbea: yes, sound is nice
21:21 orbea: Karut: with mpv doe it happen if you try a video in a tty with --vo=drm ?
21:21 orbea: *does
21:22 Karut: what command should i run?
21:22 orbea: mpv --vo=drm /path/to/video
21:23 Karut: same issue
21:24 orbea: so, different than what I ran into
21:24 imirkin_: Karut: ok, that seems all happy
21:25 imirkin_: Karut: are you using wayland or X?
21:25 Karut: X
21:25 imirkin_: pastebin your xorg log?
21:25 orbea: not sure x or wayland matters if it occurs without either
21:26 imirkin_: sequence of debugging steps matters :)
21:28 orbea: yea, good to rule out obvious things :)
21:31 Karut: wft. after a reboot the issue only happens on fullscreen, (maybe i'm wrong)