01:33AndrewR: for karolherbst: I only have one higher-than-boot pastate, and thus (?) I can only echo 0f > /sys/kernel/debug/dri/0/pstate - this will raise core/shader clocks, and I have no way back to boot clocks or to some higher.pstate
01:42imirkin: [that's usual for those early gpu's]
09:06AndrewR: karolherbst, hello.
09:06karolherbst: AndrewR: hi
09:08AndrewR: karolherbst, anything new for me to test?
09:08karolherbst: no, just if changing pstates also change the pcie speeds
09:09AndrewR: karolherbst, it comes up with 5Gt/s according to lspci, changing pstate to only one possible (0f) changes pci-e speed back to 2.5 Gt/s
09:10karolherbst: I see
09:21karolherbst: AndrewR: could you give me your vbios? it's inside /sys/kernel/debug/dri/0/vbios.rom
09:27AndrewR: karolherbst, sorry, send via email
09:50karolherbst: AndrewR: I will have a look after work
16:00rah: [44011.499130] nouveau 0000:01:00.0: gr: GPC0/PROP trap: 00000400 [RT_LINEAR_MISMATCH] x = 64, y = 128, format = 18, storage type = 0
16:02rah: any clues?
17:48AndrewR: ooops ..I'm sure I don't have THAT much memory: [ 6.945006] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
17:55nyef```: ... Is that a terabyte?
17:55imirkin: it's expected
17:56imirkin: there's 40 bits of VM space
17:56nyef```: I've occasionally run systems that had more memory on the video card than main system memory, but...
17:56imirkin: (aka 1TB)
17:56nyef```: Ah, that's the window size, not the memory size? That makes more sense.
17:56imirkin: GART = system memory that's allowed to be accessed by the GPU
17:58nyef```: So, the DMA window. Gotcha.
17:59imirkin: it has some special implications with AGP as you're probably aware
18:00nyef```: It's been a long time since I've run an AGP system, but I still have a couple in storage somewhere.
18:01AndrewR: imirkin, may be adding this bit about _virtual_ nature of this number will be helpful ....
18:03imirkin: AndrewR: where does one stop? should the kernel output pages and pages of text about how interrupt delivery works?
18:03pmoreau: imirkin: Is there any specific command line to only run the int64 piglit tests? Or do you want me to try with the GLCTS?
18:03imirkin: pmoreau: i've already run piglit
18:03imirkin: i was actually about to push the branch
18:03pmoreau: On Maxwell?
18:04pmoreau: How did it went?
18:04imirkin: on SM30 (via Karol), SM35, and SM50
18:04imirkin: all pass
18:04pmoreau: Awesome! Congrats! :-)
18:04AndrewR: imirkin, probably not, but vram size just above was in 'real' mbytes, so I assumed GART size will also be real number (say 1 or 2 Gb on 12 GB system ram computer) and was...surprized to see this number
18:04imirkin: AndrewR: it's in real megabytes.
18:04imirkin: AndrewR: the video card can access up to 1TB of system memory
18:04imirkin: just coz you don't have 1TB of system memory doesn't make the video card any less able to access it
18:05pmoreau: Feel free to push then, I’ll happily rebase on your serie. :-)
18:11imirkin: pmoreau: i left some notes in the commit log on potential improvements
18:11imirkin: in case you're interested in doing them. you totally don't have to.
18:11imirkin: [in the commit that adds all the tgsi support]
18:12AndrewR: imirkin, so, I can assume ttm subsystem above prints more real limits, like 6Gb? "[ 6.944689] [TTM] Zone kernel: Available graphics memory: 6117664 kiB" . Guess I will try with mem=some_value to see if those stalls/hangs in unigine actualy comes from this kind of grown disbalance between graphics memory in system and vram .... (compard to my old system with just 1.25 Gb of sysram)
18:12pmoreau: I’ll start with getting my SPIR-V linking code to pass my tests, push that serie out, and then we will see. :-D
18:13imirkin: AndrewR: ttm manages vram and system memory, so yes, those are based on what's actually available.
20:46Echelon9: @imirkin: I noticed the in64 code doesn't have full test coverage in src/compiler/glsl. This is a first pass proposed Mesa patch if you're interested in taking a look. https://github.com/Echelon9/mesa/compare/test/int64-glsl
20:46Echelon9: I plan on cleaning it up and sending to the mailing list today or tomorrow
20:47imirkin: Echelon9: entirely possible. please note that neither did i write this code nor is it nouveau-specific.
20:48imirkin: #dri-devel is where discussions of such code are held, and mesa-dev is the mailing list.
20:50orbea: i'm having an odd issue with pcsx2 where a game (Guilty Gear X2) will occasionally freeze (Just stops) after while of playing, but after a minute or so it recovers fine. Its hard to reproduce as it doesn't always happen and I'm not sure what triggers it, but it happens enough that its problematic. I got a backtrace during the freeze, does this look at all nouveau or mesa related rather than pcsx2?
20:50orbea: http://pastebin.com/DY8A7qwJ Here is the pcsx2 issue report as well. https://github.com/PCSX2/pcsx2/issues/1810
20:51Echelon9: Fair enough
20:52imirkin: orbea: it's waiting on the gpu to finish some work
20:52orbea: so the gpu is stuck on something holding everything else back?
20:52imirkin: gregory38: why are you doing glReadPixels to a non-pbo?
20:53imirkin: orbea: well, glReadPixels reads the contents of the framebuffer. in order to do that, it has to wait for the relevant draw to finish.
20:54orbea: makes sense, kind of curious that its so irregular.
20:56imirkin: well, it sounds like the draw might be unexpectedly slow
20:56imirkin: a single draw shouldn't be taking a minute
20:56imirkin: it should be taking 10ms
20:57imirkin: (for a very slow one)
20:57orbea: definately longer than that.
20:58orbea: well, I need to afk for up to an hour, dogs need to walk.
20:59gregory38: imirkin: It is a bit complicated but the PS2 main core is trying to read back the PS2 GPU memory
21:00gregory38: so I need the data as soon as possible
21:00imirkin: gregory38: ah. that's unfortunate. i don't suppose you could just "not do that" :)
21:00imirkin: dolphin has all kinds of hacks in place to avoid this sort of thing. i don't know the details.
21:01gregory38: in some case, I think we can avoid it but it isn't an easy task
21:01gregory38: and the code is really called
21:01gregory38: few times
21:01gregory38: I know that it is slow
21:02gregory38: It is even slower as we need to sync the main thread with the gs thread with the driver thread with the GPU
21:02gregory38: GS is the PS2 "GPU"
21:02imirkin: right, figured you didn't need to sync to some middle stage in the processing pipeline :p
21:03imirkin: anyways, was just curious
21:15gregory38: If you need more detail, I would be available tomorrow. Good luck :)
21:20karolherbst: gregory38: planning on doing some CPU opts to make soc playable? :D
22:06kattana_: opencl anytime soon?
22:06kattana_: many programs use it
22:07imirkin: kattana_: as soon as you send patches.
22:08kattana_: I did'n mean to rush developers, but to know whether it's harder than opengl or easier
22:09imirkin: mainly no one's working on it
22:10imirkin: i guess pmoreau kinda is, but not super-directly
22:12imirkin: diff people have diff interests. if opencl is something you're interested in, i suggest getting involved and doing the work for it.
22:12imirkin: if you're not in a position to do that, then you have little choice but to wait patiently until such a person presents themselves
22:40pmoreau: kattana_: If you want to help, I’ll be more than happy to point out to you what has been done and what remains.
22:40pmoreau: Though, one thing that this work is dependent on, is SPIR-V support being mainstreamed, which does not seem to be progressing.