01:23mooboat: Hello. Is there a fix for screen tearing?
01:24imirkin: not really
01:24mooboat: I see. Is that something everyone just puts up with?
01:28HdkR: Using a compositor works around it right?
01:31mooboat: Seems to have made it worse for me.
01:33imirkin: i dunno - i never really notice it
01:33imirkin: i don't use any kind of compositor
01:34imirkin: just xf86-video-nouveau with windowmaker, no funny gnome/kde crap
01:34gnarface: do you need to set vblank_mode=1 ?
01:35imirkin: no, that's the default
01:35imirkin: the default is "no tearing"
01:35gnarface: does it just not work on some cards?
01:35imirkin: so if you're still seeing tearing, the tearing prevention stuff ain't workin
01:35imirkin: i dunno. works fine for me.
01:36imirkin: that's who i mostly care about :)
01:36gnarface: mooboat: is it just tearing in certain programs, or tearing of windows/desktops?
01:36gnarface: like window tearing while moving/resizing?
01:37gnarface: you sure you're not disabling it in the xorg.conf or something?
01:37mooboat: let me play around a moment
01:38mooboat: Alright, so as of today the issue isn't happening anymore.
01:38mooboat: I installed nouveau for the first time last night. Videos and Firefox both had tearing
01:39mooboat: tearing only occurred over images in FF
01:39gnarface: so maybe it was just an environment variable issue that cleared up when you logged in the next time
01:40mooboat: Yeah, strange. I didn't mess with anything. Seems to work fine now though.
01:40imirkin: which gpu are you on btw?
01:41imirkin: ah ok
01:41mooboat: Too many issues with the proprietary drivers, and I don't game on this machine so not need to worry about that.
01:42imirkin: i'm sure you'll find that nouveau has some issues of its own :)
01:42HdkR: imirkin: Do you have compton or something? :P
01:43mooboat: Any examples?
01:43imirkin: HdkR: just Xorg...
01:43imirkin: HdkR: what would i do with a compositor?
01:43imirkin: mooboat: well, if you don't disable 3d accel, lots of hangs :)
01:44imirkin: (thing is, every application has now decided it'd be a fantastic idea to use GL to render buttons or wahtever, so pretty much every app uses 3d now)
01:44HdkR: Mostly remove tearing. i3wm by itself also tears here. Does windowmaker do its own stuff maybe?
01:44imirkin: HdkR: certainly not... it's been around for a very long time, well before compositors were a thing
01:44imirkin: actually some of it is mitigated by the fact that i have rotated monitors
01:44imirkin: but i didn't some time ago, and still didn't get much tearing
01:45HdkR: Vertical tearing is fun as well :D
01:45imirkin: (rotated monitors = root window gets blit'd to true backing buffers)
01:47mooboat: windowmaker.. is this was Damn Small had by default? looks very similar
01:47imirkin: it's one of the GNUStep wm's
01:47imirkin: along with AfterStep and a few others
01:47imirkin: looks a lot like NeXT by default
01:48imirkin: i've been using it since ... 99 or so?
01:48imirkin: don't see any strong reason to change
01:48imirkin: (i moved to it after AfterStep changed all their stuff around to become a lot less useful)
01:48mooboat: hey whatever works
01:49imirkin: yep, that's my philosophy
02:00HdkR: Well now I was curious about getting i3wm to not tear and I turned on compton and tearing went away :P
02:00mooboat: nice :)
02:22imirkin: HdkR: amd though, right?
02:22HdkR: imirkin: Intel on my laptop
09:49paulk-leonov: hi there
09:49paulk-leonov: looking at the nouveau vieux implementation in mesa
09:49paulk-leonov: I can't really figure out what IR it takes in, does someone have a clue?
09:49paulk-leonov: or is nouveau_vieux for fixed-pipeline hardware?
10:03karolherbst: paulk-leonov: fixed pipeline
10:03paulk-leonov: karolherbst: thanks :)
10:03karolherbst: I think it can consume arb shaders though?
10:03paulk-leonov: another thing that I'm trying to figure out is what gallium drivers us what IR
10:04karolherbst: ohh wait, no
10:04karolherbst: nv30 was arb+stuff
10:04karolherbst: and that's gallium
10:04karolherbst: paulk-leonov: gallium driver use TGSI and for nv50/nvc0 nir as an option
10:04karolherbst: nv30 has it's own "compiler" which is really just an assembler
10:05karolherbst: if one is interested, one could write a full nir backend for nv30
10:05paulk-leonov: I also read about "mesa IR", is that a thing or another name for GLSL IR?
10:05karolherbst: it's a thing
10:06paulk-leonov: and am I right that it ususally goes GLSL -> GLSL IR -> TGSI/NIR -> driver?
10:06karolherbst: it should be the arb stuff
10:06paulk-leonov: ah ok
10:08paulk-leonov: another thing I'm quite confused about is what exactly a state tracker is/does
10:08karolherbst: it tracks the API state and calls into a driver where necassary
10:09paulk-leonov: so purely because GL is stateful?
10:09paulk-leonov: I see, so no state tracker for vulkan then?
10:09karolherbst: and its state has to be managed somehow
10:09karolherbst: ehhh, the argumentation with vulkan was, that gallium is probably too high level
10:09karolherbst: but maybe some could have written a vulkan state tracker
10:10karolherbst: and maybe it makes sense to go there in long term
10:10karolherbst: there is still tons of code sharing between the vulkan drivers, but we reduced that quite a lot already
10:10paulk-leonov: I see
10:10karolherbst: uhm, duplicated code I meant
10:11paulk-leonov: I see
10:11paulk-leonov: thanks again for the details (bbl)
14:40imirkin: karolherbst: NV20 has vertex shader support, as well as NV_texture_shader which is a frag-but-not-really shader. this is not supported in vieux though.
14:40karolherbst: ahh, good to know
14:44imirkin: since NV2x's are all AGP (and xbox), or integrated into laptops (NV28M), it's a bit hard to get one's hands on a working setup
14:45imirkin: NV34 (and some other NV3x's) have support for the NV25 3d class though
14:45imirkin: and so i've done some testing that way
14:45imirkin: however since it's not real, you can't fully rely on it for accuracy
14:45imirkin: i.e. something might be there because of imperfect hw emulation
16:19RSpliet: I think NV2x had an instruction limit on fragment shaders of like 8 or 16 instructions...
16:20RSpliet: e.g. not particularly useful
16:20karolherbst: that's indeed not much
16:21karolherbst: today we already use at least 8 instructions for the most basic fp :D
16:23RSpliet: I think it's only useful to support DirectX 8 or something like that
16:24karolherbst: dx9 added programmable shaders, right?
16:25karolherbst: yeah HLSL got added to dx9
16:25RSpliet: "DirectX 8.0, released in November, 2000, introduced programmability in the form of vertex and pixel shaders, enabling developers to write code without worrying about superfluous hardware state." - Wikipedia
16:25karolherbst: mhh dx7 already had programmable vps and fps
16:26ajax: no? radeon r100 was a dx7 part and definitely didn't have vertex shaders
16:26karolherbst: then wiki lies, wouldnt be the first time
16:27karolherbst: ohh wait
16:27karolherbst: I missread
16:27karolherbst: it's dx8
16:27ajax: dx8 had the wacky like n-way crossbar for texture combinination, dx9 was more like shaders as we know them
16:27karolherbst: dx9 added hlsl
16:28RSpliet: I don't suppose anyone is keen to add DX8 support to mesa for NV20 :-P
16:29karolherbst: but a fun project would be to add a nir backend for nv30
16:30karolherbst: sadly, I don't have any hardware accessible for that :(
16:31RSpliet: I have one or two AGP cards from that era...
16:31karolherbst: I have no AGP board :p
16:31karolherbst: MB with AGP I mean
16:31RSpliet: That too I think I have
16:32karolherbst: there are even PCIe cards
16:32RSpliet: Just getting increasingly tricky installing an OS on that, given how all Linux distros seem to be dropping support for 32-bit CPUs
16:32karolherbst: NV36 has pcie variants
16:32karolherbst: nv34 as well
16:33RSpliet: Yeah they do exist, I just never owned one because until 2013 I was using a 32-bit AGP machine :-P
16:35ajax: i'm almost certain there were opteron machines with agp
18:19imirkin_: karolherbst: fyi, i just use PCI nv34's - plenty of them out there
18:19karolherbst: I don't know if my MB has a PCI slot :D
18:22imirkin_: there are also PCIe variants (i have one iirc, but i also have a PCI slot, so best not to waste)
18:24imirkin_: i guess my computer's getting to be a little on the old side of things
18:24imirkin_: got it in 2010 or so
18:26karolherbst: yep.. no PCI slot
18:26karolherbst: and that's a board from 2017.. so not _that_ young
18:26imirkin_: compared to mine, it's but a pup
18:27imirkin_: anyways, yes, NV2x (and NV3X!) are limited in the number of shader instructions
18:27imirkin_: even R600 is limited in the number of shader ops
18:28karolherbst: sounds annoying
18:28karolherbst: so what's the workaround here?
21:00imirkin_: workaround for what?
21:01imirkin_: having too big a shader? simple - "don't do that"
21:24HdkR: That's how it was in the old days. You just make your shaders smaller :P
22:07karolherbst: tell that to those 5k instruction shaders :D
22:31gnarface: maybe you can like gzip them or something
22:37HdkR: lol, gzip them in to the gpu
22:40HdkR: Optimal compressed bytecode :)
23:17RSpliet: karolherbst: NV4X does not have shader binary length limits beyond "whatever fits in VRAM"
23:18RSpliet: For NV3x fragment shaders are limited to 1024 insns, vertex shaders 64K