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