01:54imirkin: glennk: if you're interested in improving nv30 driver, happy to provide some hints
07:11glennk: hmm, nv30_clear forgets to set scissor state
10:30karolherbst: glennk: looking into why gnome looks like garbage?
10:31glennk: turns out fixing the scissor state fixes the garbage
10:59karolherbst: imirkin: .. I was able to reproduce the memory corruption on main... all I had to do was to instead of using nouveau_pushbuf_validate inside nvc0_state_validate to use nouveau_pushbuf_kick
11:00karolherbst: weird thing is, it only happens when the application is using multiple threads
11:02karolherbst: wait.. that change shouldn't be necessary I think...
11:02glennk: speaking of weird, this nv43 reports a core clock of 450Mhz, but i think the spec for it is 300
11:02karolherbst: yeah well..
11:03karolherbst: ahh yeah..
11:03karolherbst: happens as well, just a little later :)
11:05karolherbst: let me understand this bo refing and bufctx stuff
11:42karolherbst: imirkin: I think that "nouveau_bo_ref(NULL, &screen->text);" in resize_text has to go
11:43karolherbst: or we have to rev the bo somewhere
11:46karolherbst: or maybe we have to ref it per context? mhh
11:49karolherbst: so.. thing is, the issue triggers only when multithreaded rendering is........
11:50karolherbst: it happens regardless :)
11:50karolherbst: ehh wait
11:50karolherbst: memory issue in csgo
13:13imirkin_: glennk: clearing isn't supposed to respect scissors... i think
13:13imirkin_: i mean gallium ->clear()
13:13imirkin_: (as opposed to GL's clear)
13:13imirkin_: clear has since gained an optional scissor param
13:13imirkin_: which is respected if you set some cap
13:14imirkin_: but i don't think we set that cap on nv30
13:14glennk: its a bit more insidious, the hardware clear does respect the scissor, and nv30 isn't setting it to cover the viewport
13:15imirkin_: on nv50, there's a "window scissor"
13:15imirkin_: which is always applied iirc
13:15glennk: so depending on prior state it may be an empty box, and the clear is effectively no-oped
13:15imirkin_: (for some definition of always)
13:15imirkin_: (i think you can turn it off, but you gotta work for it)
13:18karolherbst: glennk: sounds annoying
13:19imirkin_: glennk: you're talking about RT_HORIZ, right?
13:19imirkin_: glennk: oh, i misread. you're saying it DOES respect the scissor?
13:19imirkin_: that's ... very surprising
13:19imirkin_: there's usually an enable for that
13:20glennk: haven't seen a bit for it on nv4x
13:20imirkin_: do you have the ps3 thing?
13:40karolherbst: ugh... I found my bug
14:39karolherbst: imirkin_: soooo. if I get this "[149693.044400] nouveau 0000:01:00.0: gr: SHADER a2040800, sph: 0x040800, stage: 0x22" that probably means, that the shader the pushbuffer point to are invalid, correct?
14:41karolherbst: the hell
14:43karolherbst: I found the issue...
14:43karolherbst: soo annoying
14:43karolherbst: I think
14:44karolherbst: it just makes no sense ¯\_(ツ)_/¯
14:48karolherbst: the hell...
14:48karolherbst: oh nooooooooooo
14:48karolherbst: frigging stupid bug
14:49karolherbst: found the issue :(
14:51karolherbst: still no idea why it happens
15:08imirkin_: karolherbst: it just means there's some kind of weird error in the executed shader
15:08imirkin_: karolherbst: i think it can mean like you tried to use fp64 but fp64 wasn't enabled in the SPH
15:08imirkin_: that sort of thing
15:08karolherbst: yeah.. but not in my case
15:08imirkin_: or you're trying to do an atomic access through the l window in g space
15:09imirkin_: or it's executing random instructions that happen to hit one of these conditions :)
15:09karolherbst: soo if I explicitly update CODE_ADDRESS_HIGH in state_validate after the text bo changed even after one thread already kicked out the push buffer with the updated CODE_ADDRESS_HIGH this issue gets fixed......
15:09karolherbst: and I can't explain why that is
15:11karolherbst: and even if there would be some threads/contexts out of sync, after a few pushes it should get fixed on its own anyway...
15:12karolherbst: unless there is something resetting that value or so...
15:12karolherbst: I have no clue
15:13imirkin_: karolherbst: well ... keep in mind that you can have code executions in a pushbuf
15:13imirkin_: that refer to the "old" code segment
15:13karolherbst: imirkin_: sure.. but that I won't see this error every 0.1 seconds forever
15:13imirkin_: no, you will
15:14imirkin_: depends on how you manage multiple pushbufs now
15:14karolherbst: in order
15:14imirkin_: in order of what
15:14imirkin_: if it's in order, then why do you need multiple pushbufs :p
15:14karolherbst: other reasons :p
15:14karolherbst: future optimizations mainly
15:14imirkin_: that's my point though
15:14imirkin_: if it's REALLY in order, then you wouldn't have this problem.
15:15karolherbst: something is messed up
15:15karolherbst: not everything gets submitted in order though
15:16karolherbst: the issue is just when something touches state
15:16karolherbst: but even there you can have parallelism: one thread adds stuff to its pb to update state, another adds stuff to execute stuff based on current stuff and is allowed to push, where the other has to wait until the work is submitted or so
15:16karolherbst: but there are more things you can do
15:17karolherbst: but that's for the future
15:17imirkin_: which is why i warned you against having multiple pb's
15:17imirkin_: because this stuff becomes hard.
17:25felco: 14:25:25 up 2 days, 12 min, 1 user, load average: 2.68, 3.28, 3.53
17:25felco: yeah guys, disabling accel did the tricky :/
17:30imirkin_: felco: cool, you should let your distro know that they shouldn't be shipping nouveau 3d accel by default i guess?
17:46juri_: sad. :/
17:46imirkin_: it's the reality
17:47imirkin_: the alternative is tons of applications having code which detects nouveau and avoids GL usage, for example
17:47imirkin_: imo the distro not shipping nouveau is vastly better
18:09juri_: the distro could try adding manpower.. but yeah. :/
18:15vv221: I have a laptop with one of these awful hybrid graphics stack (Intel chipset + nVIDIA GPU), with a GTX 1050. Last time I tried to use it I ended up giving up on the nVIDIA GPU and disabled it to rely only on the Intel chipset.
18:15vv221: I plan to give it another try soon, probably a bit after Debian Bullseye release so the Debian Sid installed on this computer has fresh packages.
18:15vv221: Any pitfalls I should be aware of?
18:17Kerum_: pretty sure GM200 and above cards, which includes yours, do not support reclocking
18:17Kerum_: so expect poor performance
18:18vv221: Sure, I’m aware of this limitation ;)
18:18Kerum_: on my laptop with HD 4600 + GM107M the nvidia card performed even worse than intel until i reclocked the card, which mine fortunately supports
18:18vv221: I don’t really expect to get better performances than what I get with the Intel chipset.
18:18Kerum_: other than that i do not know of any pitfalls
18:18Kerum_: just keep linux and mesa up to date
18:19vv221: What do you use to switch between intel and nvidia on your setup? I read here and there that bumblebee is mostly a thing of the past.
18:19vv221: I think I tried DRI_PRIME last time, but with no success.
18:19Kerum_: DRI_PRIME=1 <game>
18:19Kerum_: oof, that works for me
18:20vv221: OK, I think the Arch Linux and Gentoo wikis have some good documentation about that.
18:20vv221: No special kernel param to pass on boot?
18:21RSpliet: None. Just that
18:21imirkin_: vv221: so like one source of weirdness is that if you have displays attached to the nvidia gpu, the contents they display will still be drawn on the intel gpu
18:22imirkin_: and if you offload onto the nvidia gpu, then it will render on nvidia, copy to intel, and then copy back out to nvidia for display
18:22Kerum_: thats nasty
18:23Kerum_: definitely losing a fair amount of frames there
18:24vv221: I do not plan to use that laptop with an external display, it’s mostly a setup dedicated to experimenting with non-free video games and nouveau with "poor performances" constraints ;)
18:24RSpliet: the perfect use-case for nouveau!
18:25RSpliet: But yes. Gnome shell has a right-click menu item to launch an application on the discrete GPU. It is that simple, so we got that going for us, which is nice...
18:25vv221: OK, I guess during my previous tests session I overthought all of this and messed things up trying to fix them…
18:26imirkin_: when you do try it, and invariably have problems, feel free to come here and ask
18:31vv221: I’m probably going to have this IRC channel open during the whole process ;)
18:33vv221: About the lack of reclocking support, is this something that there is hope to fix with time? Or is it more probable that this GPU will forever be stuck on the lowest clock frequency?
18:33Kerum_: there probably will be no fix ever
18:33Kerum_: the reason these cards cant be reclocked in the 1st place is because the firmware used for that must be signed
18:34imirkin_: that's part of the reason
18:34imirkin_: the other part is that it's impossible to trick the blob driver into giving up the secrets of reclocking anymore
18:37vv221: So what would be the latest generation with full support from nouveau?
18:37Kerum_: 1st gen maxwell
18:37Kerum_: so GM1xx
18:37Kerum_: actually there isnt really any with full support
18:38vv221: When I get some money to spare, I would not be fully against getting another nvidia setup with decent performances ;)
18:38Kerum_: but up to GM1xx most work
18:38vv221: (even if my main setup is of course powered by a AMD GPU)
18:38Kerum_: vv221: honestly the future of free software graphics drivers looks bleak
18:38RSpliet: Nah, AMD and Intel are still doing fine
18:38Kerum_: AMDGPU "free" drivers load plenty of nonfree firmware
18:39Kerum_: and even intel can load nonfree firmware, although its not required
18:39Kerum_: but we all know intel isnt too performant
18:39vv221: Well, it’s a compromise I’m ready to make (the AMDGPU one). But the fully non-free nvidia driver is not an option I’m OK with.
18:40imirkin_: Kerum_: all hardware is shipped with non-free firmware these days
18:40Kerum_: if you want 100% free graphics your best bet is a pre skylake intel iGPU
18:40imirkin_: so it's something you have to live with
18:40imirkin_: CPUs have non-free firmware
18:40Kerum_: thats where openpower comes in
18:40Kerum_: and hopefully riscv will be good
18:41imirkin_: like i said ... if you're concerned about non-free firmware, current desktop isn't for you.
18:41imirkin_: and splitting hairs over whether the firmware is loadable or not seems counterproductive to me
18:41Kerum_: that is very much correct
18:41Kerum_: but i have no other option, at least at the moment
18:41imirkin_: so all the people claiming that nouveau is somehow 'libre' while amdgpu is not is ... BS to me.
18:42Kerum_: it would be pretty nice if i found a libreboot capable thinkpad in a dumpster
18:43vv221: As usual when working close to the hardware, it’s mostly a question of "libre enough".
18:43vv221: Kerum_, I have two of these ;) (Thinkpad X60 and X200)
18:43Kerum_: good for you
18:43karolherbst: and if it's even security relevant
18:43vv221: But the Intel graphics chipset on the X200 is a bad joke…
18:43vv221: Software rendering works better.
18:43Kerum_: i really hope we get a 100% libre ISA soon
18:44Kerum_: one can only dumpster dive for old thinkpads for so long
18:45vv221: You can find hardware with libreboot pre-installed on https://retrofreedom.com/ (but the prices are almost crazy)
18:45imirkin_: Kerum_: by now it won't be in the dumpster. it'll be in the dumpster that people throw dumpsters into :)
18:45Kerum_: vv221: prices are exactly why that isnt an option either
18:46vv221: I fully understand that.
18:46karolherbst: I thought risc-v was the savior or something
18:47RSpliet: Yeah... still working on that one
18:47imirkin_: RSpliet: work faster
18:49RSpliet: imirkin_: well if you want to help my current employer out with that working faster, be my guest :-P https://www.imaginationtech.com/careers/vacancies/?job=497367
18:50imirkin_: RSpliet: somehow i don't think they'd hire me for that job
18:50imirkin_: the only part of that i qualify for is 'senior'
18:54RSpliet: Dno, you might be overqualified for that part
18:54RSpliet: I'm senior apparently
18:57karolherbst: RSpliet: well, up to you :p
19:01imirkin_: RSpliet: you mean for the senior part?
19:01imirkin_: like geriatric? :)
19:01imirkin_: i was thinking more the 'cpu designer' bit
19:01imirkin_: not exactly me in a nutshell.
19:01imirkin_: i know how to use cpu's
19:14juri_: speaking of hiring, i'd be amiss if i didn't mention my employer. www.wire.com/en/jobs/ . we do 90+% AGPLv3 free software.
19:54FLHerne: RSpliet: Imgtech and "libre" do not belong together in my mind :-/
19:55FLHerne: I don't suppose there's any hope of decent PowerVR support this millennium?
19:58RSpliet: FLHerne: I know they were hiring a while ago for an OSS driver role. No idea where that is going. I wouldn't believe it until the code is out there
20:03imirkin_: juri_: just a silly q .. what is "m/f/d" at the end of each job title?
20:09karolherbst: imirkin_: gender
20:09RSpliet: imirkin_: I presume it's "male/female/diverse". In gendered languages it's been habit to add "(m/f)" behind a role since as long as I can remember because, to give a Dutch example, it'd be easier to write "Chauffeur (m/v)" than "Chauffeur/Chauffeuse". I presume the "d" is part of further inclusivity
20:10karolherbst: RSpliet: no idea why people just leave it out :D
20:10karolherbst: *just don't
20:11imirkin_: huh ok
20:12imirkin_: never seen that before. but also never looked for a job in a country with a gendered language :)
20:12karolherbst: imirkin_: has nothing to do with gendered language :D
20:13karolherbst: they are just positions, where it was common to only accept people from one gender
20:13karolherbst: yeah.. but these days it's hardly legal anywhere, so I don't see the point by writing it out anyway :D
20:13karolherbst: but that's more or less the origin
20:14karolherbst: e.g. male waiters in hooters might be a bit out of brand or something :p but apparently they started to do that as well :D
20:15karolherbst: in the past this was often without any reason
20:15karolherbst: or purely based on social standards or something
20:16RSpliet: karolherbst: it probably became a thing in the 70s, at least in the Netherlands. It's before my time, but I suspect it's not entirely a coincidence that it appeared in NL and DE, but not English-speaking countries. A teacher is a teacher is a teacher, but a Lehrer is not a Lehrerin.
20:17RSpliet: Anyway, regardless of history, it's to clarify that the position is open for all
20:18imirkin_: dunno about other countries, but in certain professions it's entirely legal to restrict on gender and other completely arbitrary things (looks, weight, whatever)
20:19imirkin_: imagine for example actors in movies
20:19imirkin_: (or plays, etc)
20:19imirkin_: i don't know what the legal differentiation of an actor in a movie is compared to a software engineer
20:20imirkin_: in terms of what it's legal to restrict on and what's not
20:20karolherbst: yeah.. as long as you have a good reason, even if it's simply "your brand" or something
20:20imirkin_: but i'm moderately sure it'd be illegal to discriminate for software engineers on those things
20:21karolherbst: yeah, should be
20:21karolherbst: but in germany you really find this nearly everywhere
20:22karolherbst: and sometimes people make jokes about it
20:22karolherbst: in german you'd write (m/w/d) and some say it means (translated): male/white/german :p
20:22imirkin_: the WASP equivalent, eh?
20:23karolherbst: I guess so :D
20:23imirkin_: (except for wasp, there is only one non-insect meaning)
20:23karolherbst: m/w/d translated as intended does mean male/female/divers, but both version fit
21:06karolherbst: fixed the issue and it was as stupid as I thought it would be :O
21:26imirkin_: what was it?
21:26karolherbst: the screen pushbuf was used to update CODE_ADDRESS, which shouldn't be touched by a context at all :)
21:27karolherbst: so it actually didn't got kicked out