00:08 imirkin: random_dousche: should work with drm-next + latest linux-firmware
00:08 imirkin: random_dousche: er wait, cancel that. GP107. nevermind.
00:09 karolherbst: uhm, how does this make any sense? "(0 << 8) | 1"
00:10 imirkin: probably in reference to the fact that there's a bitfield at offset 8, and it will have the value 0
00:10 imirkin: sort of like code documentation
00:10 karolherbst: BEGIN_NVC0(push, NVC0_CP(CB_BIND), 1); PUSH_DATA (push, (0 << 8) | 1);
00:11 karolherbst: yeah, okay, makes sense
00:19 karolherbst: ohhh okay, that 0 makes sense now
00:21 imirkin: ;)
00:24 Lyude: imirkin: re: your review on the nv_fill_rectangle tests for piglit. When you say "200~but please also add a test with a geometry shader that outputs triangles, points, and lines (i.e. 3 in addition to the 2 additional ones from before)
00:24 Lyude: ...i wasn't finished typing weechat
00:25 Lyude: anyway: do you mean just using GL_FILL, GL_POINT, etc.?
00:26 karolherbst: .... yeah, changing nvc0_compute will have anny effect on my kepler gpu... silly me
00:30 karolherbst: ups... gr: M2MF 80000002 [PUSH_NOT_ENOUGH_DATA]
00:33 karolherbst: what'S sph? gr: SHADER a0040800, sph: 0x040800, stage: 0x20
00:33 karolherbst: shader program header?
00:45 imirkin: Lyude: no
00:45 imirkin: i mean instead of GL_TRIANGLES, do GL_POINTS and GL_LINES
00:46 imirkin: and for the GS, just always do GL_POINTS, but make the GS output points, lines, and tris (in different test cases)
00:46 imirkin: and for the tess ones, all inputs have to be GL_PATCHES
00:46 imirkin: and the tess eval shader determines the output primitives there
00:46 imirkin: Lyude: if you're confused, that's a good sign. i'd be more concerned if you weren't confused.
00:48 Lyude: hehe, of course :P. honestly at this point I've jumped between so many different projects in different places I'm very used to being confused
00:49 imirkin: so basically
00:49 Lyude: imirkin: so I'm guessing for the geometry shader we just pass the drawing as GL_POINTS, change the mode from the perspective of the geometry shader as opposed to doing it in the [test] section, and then have piglit test if what gets rendered is what's expected?
00:50 imirkin: this pipeline is crazy-weird, coz it evolved over time, etc
00:50 imirkin: in the days of just vertex/frag processing
00:51 imirkin: you fed points/lines/triangles in, the vertex shader modified vertices, the rasterizer would rasterize the primitives, and presto! - your pretty image appears
00:51 imirkin: then they were like
00:51 imirkin: well wouldn't it be such a clever idea if we put this huge serialization point in our massively parallel pipeline
00:51 imirkin: and call that thing a geometry shader
00:51 imirkin: which would consumer one assembled primitive, be it point/line/triangle, as determined by the inputs
00:52 imirkin: and then output an arbitrary quantity of other primitives, not necessarily the same ones
00:52 imirkin: so basically you can e.g. have points on input, and the GS can produce triangles or lines as a result, and that's what should be rasterized
00:52 imirkin: then later, they were like "well maybe that serialization point was not such a great idea afterall, let's do something else"
00:53 imirkin: tess shaders are pretty clever, in that they take arbitrary primitives (aka sets of control points), which are converted by a tess control shader
00:53 imirkin: this thing takes one patch on input, and produces a *different* patch on output, potentially with a diff number of vertices
00:53 imirkin: so that + the various varyings make up the patch that's fed into the tesselator
00:54 imirkin: the tessellator then evaluates various points on the patch (in a clever and generic way) using the tess evaluation shader, which provides the proper varyings for that vertex (as well as its position, etc)
00:54 imirkin: those vertices are assembled into primitives which are then fed to the next stage (either GS or rasterizer)
00:54 imirkin: the tess evaluation shader also specifies how those vertices should be assembled - either triangles, lines, or points
00:55 imirkin: so.... to bring this about ...
00:55 imirkin: what really matters for NV_fill_rectangle is the primitive that hits rasterization
00:55 imirkin: not the primitive as it was when It All Began (tm)
00:55 imirkin: and since it should have no effect when the primitive is a point or line
00:56 imirkin: it'd be nice to test that that's the case even when it starts out as a tri
00:56 imirkin: and similarly make sure that the effect is present when it starts as a line or point, and ends as a tri
00:57 Lyude: okay, I -think- I follow you but I don't think I'll really know until I'm a bit further into this
00:57 Lyude: so expect me to possibly poke you with more questions :)
00:57 imirkin: sure
00:57 imirkin: this is all pretty generic 3D graphics stuff, nothing nvidia specific
00:57 Lyude: i figured
00:58 imirkin: so others (in e.g. dri-devel) should also be able to answer questions
01:00 imirkin: [and there's a lot more general GL knowledge in #dri-devel than there is here]
01:01 Lyude: ah, right, I'll poke them as well and not put everything on you :P
01:01 imirkin: well, i'm also not around 100% of the time
01:02 Lyude: of course
01:08 airlied: imirkin: could have foold me :-P
01:28 imirkin: airlied: try me in your afternoon :)
03:37 Horizon_Brave: evening folks
14:03 imirkin: is anyone aware of XCOM Enemy Unknown misrendering on nouveau?
14:05 gnarface: it would be a surprise to me that it would be expected to work
14:07 gnarface: have not actually tried it
14:08 pmoreau: imirkin: I had a report for XCOM Ennemy Within, which is an extension of Ennemy Unknown.
14:08 gnarface: it's the unreal engine i think
14:09 gnarface: i thought unreal v4 but google suggests v3
14:09 imirkin: i'm starting it now...
14:09 pmoreau: I haven’t tried playing Ennemy Unknown, just checked that the screen menu did not misrender.
14:09 imirkin: getting some wrong frames displayed in fullscreen mode
14:09 gnarface: great game btw
14:09 pmoreau: Yes, but it can be soooo frustrating!
14:13 pmoreau: imirkin: I can fire up EU on the GM206, see if I get the same misrendering as with EW.
14:14 imirkin: well, it's workign for me on GF108
14:14 imirkin: at least ... on first glance
14:14 imirkin: i'll try on GM107
14:14 imirkin: mattst88 claims his GM107 was having issues with it
14:15 pmoreau: Could `MESA_DEBUG=flush` help there as well?
14:19 imirkin: grrr... stupid steam
14:19 imirkin: how do i tell it to use a DRI_PRIME setting?
14:19 dboyan: imirkin: game properties -> set launch options
14:19 imirkin: and what do i put in those launch options?
14:19 imirkin: it's just an empty dialog
14:20 dboyan: DRI_PRIME=1 %command%
14:20 imirkin: wait, will this work:
14:20 imirkin: DRI_PRIME=1 steam steam://rungameid/12345 ?
14:20 imirkin: [i assume not]
14:20 gnarface: no dude, steam is hella stupid
14:20 dboyan: just use %command% is fine
14:20 gnarface: but the launch otpions are basically a command line
14:20 imirkin: well, i just saw a claim that it would, but that made no sense.
14:21 gnarface: yea it's really dumb
14:21 imirkin: gah! that dialog doesn't accept middle-click pastes
14:21 imirkin: Plagman: --^
14:21 imirkin: really annoying for pasting a thing like "pci-0000_04_00_0"
14:25 imirkin: yeah, looks like mattst88 was right. at least the "prerecorded" scenes have a lot of fail. i think in-game it's better, but hard to tell since i'm not familiar with it.
14:26 pmoreau: I don’t seem to be getting much misrendering in EU on the GM206. There are some scarce glitches, but it could be due to the card running so slowly
14:26 imirkin: well, this is with GM107, and i got a bunch. and i had reclocked the card.
14:26 imirkin: but it was perfect on GF108
14:27 pmoreau: Hum
14:27 imirkin: so ... something maxwell-related =/
14:27 imirkin: i think they changed stuff around, and we never did a proper RE of the 3d stuff
14:27 imirkin: just assumed it was all the same
14:27 imirkin: since it kinda was :)
14:28 pmoreau: Is it the same issue than when you replied my trace on your GM107?
14:28 imirkin: i don't remember your trace
14:28 imirkin: what was it of?
14:28 pmoreau: https://bugs.freedesktop.org/show_bug.cgi?id=100177
14:29 pmoreau: XCOM Ennemy Within, the extansion of XCOM Ennemy Unknown
14:29 imirkin: ah.
14:29 imirkin: let's check
14:30 imirkin: oh right. yes. some of that glitches, but i think there were others during the pre-game intros as well
14:30 imirkin: i.e. where it has the choreographed action sequences
14:31 imirkin: we must be missing a flush of some type somewhere
14:32 pmoreau: The only thing that glitches for me in EU, is the briefing part in the plane, right before a mission. Otherwise, it runs fine
14:33 imirkin: yeah, in-game it seemed mostly fine
14:34 imirkin: i.e. when you control the soldiers and whatnot
14:34 imirkin: but all the animation sequences were buggered
14:34 imirkin: mattst88: is that consistent with what you saw?
14:34 pmoreau: For me, only the animation in the plane are bugged. The ones before that, when the aliens actually land and trap some civilians, that was fine.
14:35 pmoreau: `MESA_DEBUG=flush` only works on debug builds I guess?
14:35 imirkin: probably
14:36 imirkin: not sure.
14:59 jamm: imirkin: i'm gonna compile drm-next kernel now. These are the nouveau specific configs in linux/.config:
15:00 jamm: argh, it's not copying.
15:02 dboyan: jamm: I guess you can drop a pastebin link
15:02 jamm: dboyan: yeah, doing just that
15:06 jamm: dboyan: http://pastebin.com/dNi6Z8G0
15:06 jamm: seems like my vim doesn't support copying to clipboard -.-
15:08 pmoreau: On Arch, vim from the vim package does not have copying to clipboard, but vim from the gvim package has
15:09 dboyan: jamm: the config seems okay, same as the config of my distro
15:09 jamm: pmoreau: used vim-gtk and seems to work now ^_^
15:09 jamm: using debian here
15:10 pmoreau: Ok :-)
15:13 imirkin: the nice thing about clipboards, is that there are so many to choose from
15:13 imirkin: i'm sure it works just fine with the "middle-click" clipboard
15:14 imirkin: either way, multi-line pastes are strongly discouraged on irc
15:19 pmoreau: imirkin: `MESA_DEBUG=flush` fixes the glitches I was seeing with EU. Going to try on EW.
15:20 imirkin: i'm sure it does... that doesn't make me feel any better though =/
15:20 imirkin: i think it has to do with the vbo translate stuff =/
15:20 imirkin: that's one area that maxwell is different from earlier gens
15:20 imirkin: and we might not handle that with all the required grace
15:20 imirkin: it used to be a rare case which became a common case on maxwell
15:21 pmoreau: :-/
15:21 imirkin: i'll look and see if there's a way to force it onto the "good" path somehow
15:22 pmoreau: Do you need some traces? Results of piglit runs?
15:22 pmoreau: Yep, works as well for EW.
15:22 imirkin: i need a patch which fixes the issue ;)
15:22 pmoreau: Eh eh eh :-D
15:23 pmoreau: You are not asking for much :-)
15:23 imirkin: just the key to the room where the money lies.
15:24 imirkin: this is not the first time i've suspected that code of wrongdoing, but this is the first time that i hear that MESA_DEBUG=flush helps while suspecting that code :)
15:24 pmoreau: ;-)
15:25 pmoreau: Going to switch to a Fermi to test Roy’s code, and then I can switch to a Pascal to test your patch.
15:27 imirkin: get more pcie slots :)
15:29 pmoreau: I do have a 3xPCI-E slot MB, but I keep plugging in only one card --"
15:30 pmoreau: Too afraid of possible Nouveau reacting badly to the multi-card configuration, or to one of the cards, and screwing up the test
15:30 imirkin: meh
15:30 imirkin: i have 4 plugged in
15:30 imirkin: https://hastebin.com/puzihiqaya.css
15:31 pmoreau: I guess it may be my experience with the G96+MCP79 in my laptop
15:31 pmoreau: Neat
15:47 pmoreau: Grrr… a sneaky update of the nvidia package reinstored the blacklisting of Nouveau. and I was trying to figure out what I had messed up while building the kernel which would have resulted in Nouveau not loading… --"
16:07 Plagman: imirkin: argh, yeah it does that
16:52 pmoreau: imirkin: Ok, so, what do I need for testing the GP10x? drm-next + Ben’s tree, latest xf86 + your patch, and Mesa head?
16:54 karolherbst: pmoreau: were you able to create some mmiotraces on the pascal one?
16:54 pmoreau: I haven’t tried
16:54 karolherbst: okay
16:55 karolherbst: I think I will try to get reclocking working on pascals as well, after I finally get access to one or so
16:55 pmoreau: One more project? :-D
16:55 karolherbst: and I should finally fix nvbios for pascal vbios files :( *sigh*
16:56 karolherbst: pmoreau: I am sure it will take 2+ months until I get one
16:56 karolherbst: also: we can't RE the vbios, so I doubt it will be something I can finish in a few months
16:56 pmoreau: Yeah…
16:56 karolherbst: but maybe those things aren't that different
16:56 pmoreau: That’s unfortunate
16:57 karolherbst: allthough I am sure they are super different
16:59 karolherbst: how has push rights to mesa by the way? So that I don't have to poke imirkin for reviewing my patches all the time
17:00 pmoreau: hakzsam has, as well
17:00 karolherbst: k
17:01 karolherbst: mhh well, he is now occupied with other things mainly I guess
17:01 pmoreau: I guess he is, but he might still have time to push a few patches that have been reviewed.
17:04 karolherbst: it's more like that reviewing is the bigger problem I think then
17:04 pmoreau: AH, ok
17:04 pmoreau: Which patches are you talking about?
17:04 karolherbst: well depends on the patches, because currently I have 2 patches pending with -/+3
17:04 karolherbst: pmoreau: https://lists.freedesktop.org/archives/mesa-dev/2017-March/149051.html and https://lists.freedesktop.org/archives/mesa-dev/2017-March/149052.html
17:05 karolherbst: and after that I want to work on my other patches and mainline them before doing new stuff (otherwise it just piles up)
17:06 pmoreau: Makes sense
17:07 pmoreau: I’ll try to have a look at them, but I don’t think I have the knowledge to review them. Will investigate how things work.
17:07 karolherbst: I only have codegen patches for mesa
17:11 pmoreau: Cool, the setup with the updated xf86-video-nouveau seems to be working. Time to get the Pascal in.
17:11 karolherbst: :)
17:12 imirkin: pmoreau: sounds right. actually mesa 17.0 should work i think? not sure.
17:12 pmoreau: I can try with both :-)
17:12 imirkin: pmoreau: importantly you need updated linux-firmware
17:12 pmoreau: Ah right, I need to check that
17:13 pmoreau: I have it already, cool
17:15 pmoreau: Ah, I understand better why "the latest" version of xf86-video-nouveau was only 1.0.13: the local clone I had was pointing to your repo imirkin, rather than the official one, and you haven’t updated it yet :-D
17:15 pmoreau: Need to change the remote here
17:15 imirkin: hehe
17:16 imirkin: my patch isn't in my repo either
17:16 pmoreau: I downloaded from patchwork
17:16 imirkin: cool
17:16 imirkin: the v2 i hope
17:16 imirkin: (there's a patchwork pointed at nouveau@ ? news to me...)
17:16 pmoreau: Yup, the v2
17:17 karolherbst: imirkin: should I also CC nouveau@ in mesa series?
17:17 pmoreau: Yes, it is visible fom https://patchwork.freedesktop.org
17:17 pmoreau: https://patchwork.freedesktop.org/project/nouveau/patches/
17:17 imirkin: karolherbst: you can, but don't have to
17:17 karolherbst: k
17:18 karolherbst: maybe I do it, because it makes sense
17:30 pmoreau: (time to plug in the beast and hope nothing blows up… :-/)
17:37 pmoreau: :-/
17:38 imirkin: ka-boom?
17:39 pmoreau: gnurou: acr_r352_bootstrap seems unhappy with my GP102 (Titan X) https://hastebin.com/vudesehowi.go
17:39 pmoreau: "nouveau 0000:03:00.0: secboot: cannot boot FECS falcon"
17:41 pmoreau: and before that, a timeout while reading something in acr_r352_bootstrap. I guess the error message should be different if it didn’t find the firmwares.
17:41 imirkin: pmoreau: i'm about 99% sure it won't make a difference, but mind booting with nouveau.runpm=0 ?
17:41 pmoreau: Sure
17:42 imirkin: [ 2.211444] nouveau 0000:03:00.0: fb: 12288 MiB of unknown memory type
17:42 imirkin: hehe
17:42 pmoreau: I had missed that :-D
17:42 karolherbst: !
17:42 imirkin: probably the GDDR5X?
17:42 karolherbst: pmoreau: could you upload your vbios pls? :D
17:42 kattana: I NEEDED THIS YESTERDAY!!! --> https://www.kraxel.org/blog/2017/01/virtual-gpu-support-landing-upstream/
17:42 pmoreau: Should be GDDR5X, only the GP100 had HDM2…
17:43 karolherbst: pmoreau: ohh true
17:43 karolherbst: pmoreau: https://github.com/envytools/envytools/commit/5736c55036dba9dddba0aad7650abf1d8e401824
17:43 karolherbst: so if you want to write a patch for the unknown memory type
17:43 kattana: relevant text part "BOTH NVIDIA and intel will use mdev to partition the physical gpu of the host into multiple virtual devices which then can be assigned to virtual machines."
17:44 kattana:starts drooling profusely
17:45 Horizon_Brave: hey everyone, happy saturday
17:45 kattana: after all my card isn't that all useless
17:45 pmoreau: imirkin: Nope, still unhappy :-/
17:45 pmoreau: Horizon_Brave: Hey
17:47 karolherbst: pmoreau: could you check if an unknown memory type may break something?
17:47 karolherbst: cause vram is used for secboot afik
17:47 kattana: am I the only one excited abouth the prospect of 'virtual gpu support (vgpu)' ???
17:47 pmoreau: karolherbst: I can have a look
17:48 karolherbst: but I think it is a littile odd, that GDDR5X isn't detected, cause I would assume skeggsb already added support for detecting this
17:50 karolherbst: indeed he hasn't
17:51 karolherbst: nvm then
17:56 pmoreau: Yup, not sure I feel like implementing a `gp102_ram_train()` out-of-the-blue on my work card :-D
17:56 karolherbst: :D
17:57 mattst88: imirkin: yeah, what you describe is what I saw
17:57 mattst88: there was some (though a lot less) misrendering during actual game play
17:57 imirkin: mattst88: ok. well, i see it too, and it apparently goes away with MESA_DEBUG=flush.
17:57 imirkin: although i haven't confirmed it
17:58 mattst88: oh, interesting
17:58 imirkin: unfortunately MESA_DEBUG=flush is a GIANT hack which wipes away a whole array of faults
17:58 pmoreau: imirkin: Sorry, I can’t test then until someones add GDDR5X support; and the other card I have access to also has GDDR5X.
17:58 imirkin: almost as bad as apitrace + readpixels on every draw :)
17:58 imirkin: pmoreau: no worries. just save your vbios somewhere for others to drool over
17:59 pmoreau: :-D
17:59 imirkin: the issue is you need a memtype_is_valid or something for it?
18:00 imirkin: on, and a new NVKM_RAM_TYPE. ok yeah, a bunch of stuff.
18:00 pmoreau: I was starting to add the NVKM_RAM_TYPE and stuff, but then I realised I would need to train it as well… and then, it didn’t seem like I could do that :-D
18:01 karolherbst: pmoreau: just use the gddr5 stuff
18:01 karolherbst: :p
18:01 imirkin: no need to train
18:01 pmoreau: karolherbst: And I don’t want to risk the card either! :-p
18:01 imirkin: you're not doing reclocking
18:01 pmoreau: Ah, ok
18:21 jamm: should i install the dbg kernel image or the normal one?
18:22 jamm: running make on the drm-next tree generated multiple linux installation packages (for debian)
18:22 pmoreau: karolherbst: …
18:22 karolherbst: pmoreau: it works now?
18:22 pmoreau: karolherbst: Look at commit 758b06 in the VBIOS repo
18:23 karolherbst: ahh, thanks
18:23 pmoreau: That’s not what I mean! Look at the spelling! :-p
18:23 pmoreau: in the commit message and the folder name
18:24 karolherbst: ohhh
18:24 karolherbst: the u
18:24 pmoreau: yup
18:24 karolherbst: sry
18:24 pmoreau: bad Karol, bad! :-D
18:29 pmoreau: karolherbst: Pull that repo, there might be something for you. ;-)
18:36 karolherbst: will look at it after I got proper internet here
18:36 karolherbst: currently online via my phone
18:36 pmoreau: :-/
18:36 pmoreau: Probably not the best place to look at binary files
18:36 karolherbst: I should get internet next week (tm)
18:36 pmoreau:crosses fingers
18:37 karolherbst: well 1GB costs me 5€ right now
18:38 RSpliet: sry, w'l tpe shrt sentncs
18:39 karolherbst: ty
18:42 karolherbst: mupuf: if you got time, mind if you review the remaining patches of my last clocking series? Or is everything else fine as it is?
18:48 pmoreau: gnurou: (in case you didn’t read the conversation since my previous message) Nevermind, the error most likely comes from Nouveau not handling GDDR5X-type memory.
18:57 jamm: hey guys, i installed the kernel (drm-next 4.11.0 rc3) but on booting it up nouveau says "unable to load gr/sw_nonctx" and the display starts blinking at a rapid speed for a minute or so.
18:57 jamm: then i booted back to 4.9 (which i was running on before) and things seem to work fine.
18:58 jamm: am i missing something? perhaps that gr/sw_nonctx?
18:58 karolherbst: jamm: tegra?
18:59 karolherbst: jamm: updating linux-firmware might help
19:01 jamm: karolherbst: 1080. I mistakenly deleted all nvidia related packages using "apt purge". Will reinstall firmware-linux on debian and try again. brb
19:02 karolherbst: ohh, gp102, okay, there as well, true
19:02 jamm: oh, i don't see a gp102 folder in /usr/lib/firmware/nvidia though
19:02 karolherbst: you need one
19:03 karolherbst: maybe you need an even newer version
19:03 karolherbst: the files are quite new
19:04 jamm: okay, will get em from linux-firmware
19:14 karolherbst: I swear, whoever is finding the cause for this sille OOR_ADDR issue will get a night of bear drinking on my costs :O
19:14 jamm: awesome! it works now. Thanks karolherbst !
19:21 pmoreau: jamm: Not having issues with Nouveau on the 1080? It should also have GDDR5X which Nouveau does not support yet
19:22 nyef: Final test for HDMI 3D + audio on GT215: Passed.
19:23 nyef: Now I "just" need to come up with a better rule for when to enable stereo modes on a connector.
19:23 karolherbst: pmoreau: well, seems like your GPU is simply broken
19:23 pmoreau: karolherbst: How so?
19:24 karolherbst: it just is
19:24 pmoreau: It runs fine when I use it with the blob
19:24 karolherbst: the blob just fakes it
19:25 pmoreau: It’s a fact that Nouveau does not support GDDR5X, you had a look at the code as well. Though, maybe that does not explain why the rest failed.
19:25 mupuf: karolherbst: I will review them
19:27 karolherbst: mupuf: awesome, thanks
19:29 mupuf: karolherbst: But everything is reviewed, AFAICT
19:29 karolherbst: mupuf: yeah, I was just wondering about patches you didn't reply on
19:30 mupuf: yeah, were fine before, still fine now ;)
19:30 karolherbst: well I changed all of them I think, just wanted to be sure
19:31 jamm: pmoreau: things seem to run fine for me
19:31 jamm: pmoreau: even ran a game on it, runs slower than usual but no issues otherwise
19:31 karolherbst: "slower" ;)
19:31 jamm: well, yeah XD
19:32 jamm: more choppy
19:32 pmoreau: jamm: Cool for you then. I assume Nouveau reports 8GB of unknown memory type?
19:32 jamm: pmoreau: where can i check that?
19:32 karolherbst: jamm: you need to throw in some "much" and "terribly"
19:32 pmoreau: In dmesg
19:32 jamm: [ 22.350936] nouveau 0000:01:00.0: disp: 0x64f7[0]: INIT_GENERIC_CONDITON: unknown 0x07
19:32 pmoreau: You should have something like "nouveau 0000:01:00.0: DRM: VRAM: 2048 MiB"
19:33 jamm: [ 2.602073] nouveau 0000:01:00.0: DRM: VRAM: 8192 MiB
19:33 jamm: yeah
19:33 mupuf: karolherbst: sorry, thne
19:33 mupuf: but I did check them all when I did my review
19:34 karolherbst: okay
19:34 pmoreau: jamm: Oops, wrong line. Could you look a few lines above that one, for something like "nouveau 0000:01:00.0: fb: 2048 MiB GDDR5"
19:34 karolherbst: thanks
19:34 jamm: [ 2.598794] nouveau 0000:01:00.0: fb: 8192 MiB of unknown memory type
19:34 karolherbst: mupuf: now I can annoy ben with those :D
19:34 jamm: you're right :D
19:35 karolherbst: pmoreau: maybe the proble is, that you have more VRAM?
19:35 jamm: also
19:35 jamm: [ 2.488922] nouveau 0000:01:00.0: NVIDIA GP104 (134000a1)
19:35 pmoreau: karolherbst: I only have 12GiB :-D But, yeah, maybe
19:35 jamm: heh XD
19:35 karolherbst: "only"
19:35 jamm: is it a 1080Ti?
19:35 mupuf: karolherbst: sorry, you had to wait...
19:36 jamm: actually more
19:36 pmoreau: jamm: Have you tried imirkin’s patch for xf86-video-nouveau?
19:36 karolherbst: mupuf: no problem, ben was away afaik anyway
19:36 mupuf: good then
19:36 pmoreau: jamm: The Pascal Titan X
19:36 jamm: pmoreau: no i've yet to compile that actually
19:36 karolherbst: pmoreau: you "only" have 4 times the memory I have...
19:36 jamm: awesome :D that's quite a beast of a card
19:36 pmoreau: karolherbst: I would love to have more than 12 GiB for what I am working on… 16-20 GiB would be great
19:36 karolherbst: pmoreau: ohh I .... nvm I had an idea what you could test, but you can't do OpenGL I ssume
19:37 karolherbst: pmoreau: :D
19:37 karolherbst: jamm: by any chance, do you own the newest hitman game?
19:37 karolherbst: ohh wait, you would need to compile mesa and everything, nvm
19:38 pmoreau: jamm: Would e great if you could give it a try (xf86-video-nouveau+imirkin's patch), to have another confirmation that it works.
19:38 karolherbst: I would be thrilled to know if this issue also happens on maxwell
19:38 pmoreau: Can’t test on Reator?
19:38 karolherbst: hakzsam: mind if you check something for me?
19:38 karolherbst: pmoreau: hmmm, would need to use the steam client somehow
19:39 karolherbst: for odd reasons, the issue isn't reproducible within apitrace due it's lack of buffer_storage support most likely
19:39 pmoreau: Most likely yes. I would gladly try, but I don’t have the game. And I am not elligible (yet?) for having the games for free. :-)
19:40 jamm: pmoreau: sure! for testing that, do i need to set env's like the ones mentioned under "Userspace" here? https://nouveau.freedesktop.org/wiki/InstallNouveau/
19:40 karolherbst: uhm... like I am under the current ruiles
19:40 karolherbst: I think I have 10? commits in mesa
19:41 pmoreau: jamm: The env are only for putting the stuff in the right place. To use the module, as long as you set the proper path in that conf file, it should be fine.
19:43 jamm: pmoreau: noob question, which conf file?
19:43 pmoreau: karolherbst: Oh wow, I only have one commit fewer than you (12 vs 11). Hadn’t realised I had so many 1-2 liners :-D
19:43 pmoreau: karolherbst: But if you count your kernel patches, you are way above 25 commits, aren’t you?
19:44 pmoreau: jamm: The one mentionned in that page: /etc/X11/xorg.conf.d/01-module-path.conf
19:44 pmoreau: https://nouveau.freedesktop.org/wiki/InstallNouveau/#xf86-video-nouveau
19:44 jamm: pmoreau: ah, right. Thanks!
19:45 karolherbst: pmoreau: yes
19:45 karolherbst: pmoreau: If I keep up, I even get more than mupuf :O
19:46 pmoreau: :O
19:46 karolherbst: mupuf: 65, me: 60
19:46 mupuf: karolherbst: go for it!
19:46 pmoreau: Eh eh!
19:46 karolherbst: well, that's for bens repository
19:46 karolherbst: no idea what was before that
19:46 pmoreau: Next step is catching up Ben? :-D
19:46 karolherbst: no
19:46 pmoreau: s/up/up on
19:46 karolherbst: imirkin with 89
19:47 karolherbst: then gnurou with 227....
19:47 mupuf: yeah, most of my work was on the REing
19:47 mupuf: I was pretty good at envytools commits
19:47 karolherbst: RSpliet: has 59 by the way :p sorry roy
19:47 karolherbst: mupuf: well you still need to get the fan issue resolved ;)
19:48 mupuf: yep...
19:48 mupuf: 346 commits in envytools
19:48 mupuf: but do I get points for creating the repo?
19:48 pmoreau: Ah, next to catch up for me would be Emil, with 9 commits, so only one missing… :-)
19:48 karolherbst: I only have 81 in envytolls :(
19:48 karolherbst: *envytools
19:49 mupuf: mwk started the project, but it was hosted by pathscal
19:49 mupuf: e
19:49 karolherbst: mupuf: if you get bonus points for creating, I get points for the awesome logo :3
19:49 mupuf: forked it and pushed it to the envytools group
19:49 mupuf: LOOL
19:49 mupuf: true :D
19:50 pmoreau: mupuf gets extra points for making the most useful LED driver ever ;-)
19:51 pmoreau: (which needed even more patches to get the Kconfig right)
19:51 mupuf: yep!
19:52 mupuf: I keep breaking people's system
19:52 mupuf: I even broke Intel's CI because of this LED patch
19:52 karolherbst: well LEDs _ARE_ important
19:52 karolherbst: everybody knows it
19:52 pmoreau: Ah ah ah!! Good work!
19:52 mupuf: felt proud of myself for this
19:52 karolherbst: every uber GPU system has many LEDs
19:52 mupuf: but hey, I had sent my patch for it months before
19:52 pmoreau: Stress testing should never be underestimated!
19:53 mupuf: but for the fan... I will really just ask nvidia avout this shit
19:54 karolherbst: mupuf: can't you write a patch which is good enough or can it produce very wrong values as well?
19:54 karolherbst: having something hacky in the meanwhile is most likely better than to wait for an answer
19:55 mupuf: karolherbst: nope, I can't
19:55 karolherbst: :(
19:56 mupuf: well, what I can do is find the right values for the bios I have in the vbios repo
19:56 mupuf: that I can do
19:56 mupuf: probably
20:01 karolherbst: and you could fail otherwise
20:02 karolherbst: then we have a whitelist and an error for users with new values
20:02 karolherbst: sounds like the best solution to me until we get proper knowledge
20:02 karolherbst: user care a lot about silent fans
20:04 mupuf: well, let's give nvidia a chance, I will send them an email before working on a workaround
20:05 mupuf: Yeah! The national TV of Finland (Yle) just showed a biathlon competion we broadcasted live today on their website!
20:06 mupuf: but tonight, they showed images on actual TV, fun :)
20:07 mupuf: what is left of the stream: https://youtu.be/C6Go-mvaWdI?t=41
20:08 mupuf: I was mostly filming at the finish line
20:22 jamm: pmoreau: getting configure.ac:58: error: must install xorg-server macros before running autoconf/autogen
20:22 jamm: for x86-video-nouveau
20:27 pmoreau: Well, then you need to install xorg-server macros ;-) On Arch the package seems to be called xorg-util-macros
20:28 karolherbst: what's the difference between FFMA32I and FFMA32I.S?
20:30 karolherbst: saturation I figure
20:31 karolherbst: mhh .SAT is saturatoin
20:31 pmoreau: I guess so `FFMA32I(.SAT)(.FTZ)(.FMZ) rd(.CC), (-)r1, imm, (-)r3;` (from https://hpc.aliyun.com/doc/keplerAssemblerUserGuide)
20:32 karolherbst: but there is .S !
20:32 pmoreau: On top of .SAT?
20:32 karolherbst: no
20:32 karolherbst: or maybe?
20:32 karolherbst: sat35
20:33 karolherbst: FFMA32I.SAT.S
20:33 karolherbst: for maximum confusion
20:34 pmoreau: Hum… then it’s definitely not sat.
20:35 karolherbst: it's sat3a though
20:35 karolherbst: but yeah
20:35 karolherbst: mhh
20:35 karolherbst: it is in a strange place as well
20:35 pmoreau: signed would make no sense :-D
20:35 karolherbst: 0x00400000 0x64000000 -> @P0 FFMA32I.SAT.S R0, R0, 0, R0;
20:36 nyef: Single? Short?
20:36 karolherbst: short makes no sense
20:36 karolherbst: cause it's the form with a 32bit immediate
20:37 pmoreau: Sero?
20:37 karolherbst: it's between the immediate and P_NOT
20:37 karolherbst:
20:38 karolherbst: pmoreau: well I guess mul/add should have this flag as well somehow
20:38 nyef: Is the immediate a float, or an integer to be converted to a float?
20:38 karolherbst: f32
20:39 karolherbst: pmoreau: hihi: same place: IMUL32I.U32.U32.S
20:39 pmoreau: Grrr
20:39 nyef: Hrm. Yeah, got nothing.
20:39 karolherbst: pmoreau: well mhh signed
20:40 karolherbst: it _kind_ of makes sense to be able to say: hey my immediate is signed
20:40 karolherbst: abs?
20:40 pmoreau: But not so much for floats, right?
20:40 karolherbst: no idea?
20:41 karolherbst: ohhhh
20:41 karolherbst: envydis parses it for mul
20:41 karolherbst: it's join
20:41 karolherbst: :D
20:41 karolherbst: maybe "sync" in the nvidia tools?
20:42 pmoreau: Eh? You can have a join that is not its own instruction?
20:42 karolherbst: sure
20:43 karolherbst: and you can have it on the LIMM form of fma as well!
20:43 pmoreau: Does Nouveau use that? Or does it always emit a separate sync instruction.
20:43 karolherbst: I think it uses it
20:43 karolherbst: not quite sure
20:43 pmoreau: Ok
20:45 karolherbst: now I have to teach envydis about this join for fma
20:45 nyef: Seems like the sort of thing that could be folded in with a peephole optimizer, if necessary.
20:45 karolherbst: well
20:45 karolherbst: post RA that is
20:45 karolherbst: and after flatteningpass
20:45 karolherbst: but yeah
20:45 nyef: (For the record, I am not a fan of peephole optimizers.)
20:46 karolherbst: mhh any alternatives?
20:47 jamm: pmoreau: it complains about xorg-macros not installed even after installing it. libdrm compiled fine, and even that required this package. Something seems odd with configure.ac
20:47 nyef: So far as I can see, a peephole optimizer is an indication that your code generator could be better.
20:47 karolherbst: nyef: isn't the peephole optimizer _part_ of your code generator?
20:48 nyef: No, because it operates in terms of already-generated code. It's a post-generation pass.
20:48 karolherbst: nyef: well sure, you can always do a direct glsl -> nvc0 and do everything right directly, but.... except you can't
20:48 imirkin: peephole optimization can mean a lot of things
20:49 karolherbst: that as well
20:49 karolherbst: in codegen it's before generating the program binaries
20:49 karolherbst: so it's not already-generated code
20:49 imirkin: .S = join
20:49 karolherbst: thanks, but I figured it out already :)
20:49 imirkin: ah, just scrolling through the logs
20:49 nyef: Admittedly, I'm coming from a more classical compiler background, not this GPU SIMD type stuff.
20:50 pmoreau: jamm: Hum… maybe clean everything before rerunning autogen?
20:50 karolherbst: nyef: unrelated to GPUs
20:50 imirkin: was swapping desks and a cable accidentally pressed down against the power button on the power strip :(
20:50 pmoreau: Oops… :-/
20:50 karolherbst: nyef: the nouveau peephole passes are part of the compiler and are run on top of the nv50_ir not the generated binaries
20:50 imirkin: in general, i think peephole optimizations are ones that use very local knowledge to perform whatever it is they do
20:50 karolherbst: also, the nv50_ir doesn't feel like SIMD anyway
20:51 imirkin: nvidia provides a pretty good view on the whole SIMD thing. you basically don't know it except for a few minor situations
20:51 imirkin: [and the fact that you have to structurize your code, or else you get shit-for-perf]
20:51 karolherbst: those fancy dx* instructions?
20:51 imirkin: quadop, yea
20:51 karolherbst: and shuffle now
20:51 jamm: pmoreau: fixed! i think it required xserver-xorg-dev from xorg-deg (debian package names)
20:52 imirkin: yea same diff :)
20:52 jamm: s/deg/dev
20:52 karolherbst: okay envydis... why you don't do this
20:53 imirkin: pmoreau: on nvc0+, there is no join instruction
20:53 imirkin: it's only ever a flag. you can do NOP.S if you just need to join.
20:53 karolherbst: ohh
20:53 karolherbst: that makes sense
20:53 imirkin: that said, on maxwell+, there's an explicit SYNC op, and no more .S modifier iirc
20:54 imirkin: the pattern changed between nv50 and nvc0
20:54 imirkin: on nv50, you said "joinat", and then the join op would be where the joinat said. and it would basically be the thing that declares that everything's in sync again
20:54 imirkin: whereas on nvc0+, the join is actually a jump to the "joinat" point
20:55 imirkin: [i've scanned through scrollback... are there other questions that remain unanswered?]
20:56 karolherbst: mhhh
20:56 karolherbst: what do I have to change in envyids/gk110 so that the join is displayed?
20:56 imirkin: it should be displayed.
20:57 karolherbst: it isn't
20:57 imirkin: specifics please
20:57 karolherbst: 0x00400000 0x60000000 -> fma $p0 f32 $r0 $r0 0x0 $r0 [unknown: 00400000 00000000]
20:57 karolherbst: it works for mul
20:57 pmoreau: imirkin: Ok, thanks for the info :-)
20:57 karolherbst: 0x00400002 0x28000000 -> join $p0 mul $r0 u32 $r0 u32 0x0
20:57 pmoreau: jamm: Nice
20:58 karolherbst: imirkin: it's for the LIMM form of fma
20:58 karolherbst: ohh wait
20:58 imirkin: oh
20:58 imirkin: coz someone's a jerk.
20:58 imirkin: (probably me)
20:59 karolherbst: looks like it :p
20:59 imirkin: okk.
20:59 imirkin: odd.
21:00 imirkin: { 0x00000001, 0x00400003, OP8B, T(p), T(i) },
21:00 imirkin: { 0x00400001, 0x00400003, OP8B, N("join"), T(p), T(i) },
21:00 karolherbst: yeah, it needs to be 0x00400000, ...
21:00 imirkin: no
21:00 karolherbst: no?
21:00 imirkin: no.
21:00 imirkin: this fma thing is in the control instructions
21:00 imirkin: that's why
21:00 karolherbst: ohhh
21:00 karolherbst: I move it then
21:00 imirkin: no.
21:01 imirkin: :p
21:01 karolherbst: ....
21:01 imirkin: the other limm's have a 1 at the end
21:01 karolherbst: mul has a 2
21:01 imirkin: it's where it should be. just adding a T(join) there.
21:01 imirkin: yep, that works
21:01 karolherbst: yeap
21:02 karolherbst: allthough the order of stuff is different
21:02 imirkin: fixed.
21:02 imirkin: yeah, that T(p) is in the wrong place. wtf.
21:02 imirkin: who did this. hopefully not me.
21:02 karolherbst: "join $p0 mul $r0 u32 $r0 u32 0x0" vs "fma join $p0 f32 $r0 $r0 0x0 $r0"
21:02 karolherbst: I guess it was me
21:03 karolherbst: maybe
21:03 karolherbst: I was working on those LIMM forms
21:04 imirkin: that should be better
21:04 karolherbst: nice
21:04 imirkin: now, it's actually possible that the .S flag doesn't work there - on some ops it doesn't seem to work.
21:05 imirkin: even though nvdisasm happily decodes it
21:05 karolherbst: okay
21:05 karolherbst: hw bug
21:05 karolherbst: maybe
21:05 imirkin: just ... lack of hw feature
21:05 imirkin: we have logic to exclude such ops
21:06 karolherbst: okay, my gk110 LIMM fma emit patch should be fine then
21:06 karolherbst: was checking if I got the neg mod on src 0/1 right
21:06 karolherbst: and accidentally notice that the join wasn't decoded :)
21:07 imirkin: does your patch look a lot like this patch? https://github.com/imirkin/mesa/commit/c86005f55bc5be4da9148c0f61902823f1ac11a0
21:07 karolherbst: more like this: https://github.com/karolherbst/mesa/commit/c946f4e84ffa6bd31edeaa9bd2e3e68ce7433e4b
21:08 imirkin: do you need to bother with that scount crap?
21:08 imirkin: dst == src, so ... should be fine
21:09 imirkin: should probably throw an assert in to that effect
21:09 karolherbst: scount?
21:09 imirkin: sCount
21:09 karolherbst: there was a reason I had to do this...
21:09 karolherbst: otherwise I wouldn't
21:09 imirkin: actually on second thought yeah, you do need that
21:09 karolherbst: :)
21:10 imirkin: since otherwise it'll overwrite part of the IMM
21:10 karolherbst: ahh true
21:10 karolherbst: yeah
21:10 imirkin: or something else
21:10 karolherbst: yeah
21:10 imirkin: either way, !good
21:10 karolherbst: it generated garbage
21:10 karolherbst: well
21:10 karolherbst: I doubt yours was tested :p
21:11 imirkin: insufficiently, it would seem
21:11 imirkin: i never pushed it :)
21:11 karolherbst: I ran a full shader-db through that
21:11 imirkin: because i realized the stupid dst == src thing
21:11 imirkin: and probably gave up
21:11 karolherbst: most likely
21:11 karolherbst: and you had no use case
21:11 imirkin: well, shader-db wouldn't reveal the issue
21:11 karolherbst: it will
21:12 karolherbst: ;) https://github.com/karolherbst/mesa/commit/8ee050c29b71e555b986b9d9cc5cd444ad3b2e6a
21:12 imirkin: it'd still compile
21:12 imirkin: the shader would just be garbage
21:12 karolherbst: ohh true
21:12 imirkin: but shader-db would have no way of knowing that
21:12 karolherbst: but I think there was a more obvious issue
21:12 karolherbst: anyway, I caought that one somehow
21:14 karolherbst: maybe I indeed checked the generated binaries, who knows
21:15 karolherbst: or osmebody ran piglit and told me something broke
21:16 imirkin: either way, that or something else like it has to be done :)
21:16 karolherbst: imirkin: well, the first 4 patches of my postraloadpropagation series should be pushable, I can do the RA bits later
21:17 imirkin: cool beans. send them as a series please
21:17 karolherbst: already did... let me check if thes are up to date
21:17 imirkin: sorry, i'm not very good at this maintainer thing -- i don't keep track of the patches, etc
21:17 imirkin: so, ping early and ping often
21:18 karolherbst: imirkin: okay, then this as well: https://lists.freedesktop.org/archives/mesa-dev/2017-March/149051.html https://lists.freedesktop.org/archives/mesa-dev/2017-March/149052.html
21:18 imirkin: i like 2/2, not sure how i feel about 1/2
21:19 karolherbst: that's what my postraLoadpropagation series fix though
21:19 karolherbst: but yeah
21:19 karolherbst: maybe there is a much more ellegant sollution for all this
21:20 imirkin: hm. i thought that gf100 was actually able to do this
21:20 imirkin: but it can't...
21:20 karolherbst: what do you mean?
21:20 imirkin: i thought that SOME gen could do the fma + limm + src2!=dst
21:21 karolherbst: ohhh
21:21 imirkin: but i was mistaken
21:21 karolherbst: well
21:21 karolherbst: 2 sources + 1 dest + 1 limm
21:21 karolherbst: well that makes that insturction pretty much limited
21:21 imirkin: well, with gk110+, it's pretty much destined to fail
21:21 imirkin: since there are 8 bits of regs
21:21 karolherbst: true
21:21 imirkin: but on gf100/gk104, with 6 bits of regs... who knows
21:22 imirkin: sky's the limit ;)
21:22 karolherbst: 50 bits just for the values
21:22 karolherbst: tough
21:22 imirkin: 3 more for predicates
21:22 imirkin: 1 for sync
21:22 imirkin: it adds up.
21:22 karolherbst: instruction mask
21:23 imirkin: another 5
21:23 imirkin: i dunno, i'd rather have had that and no negs
21:23 karolherbst: negs you can do by messing witht he immediate :D
21:23 imirkin: except for src2
21:23 imirkin: ftz/fmz... bleh
21:24 imirkin: anyways, will have to study the code a bit more to see what the original intent was
21:25 karolherbst: okay
21:26 karolherbst: well you can push the one patch without the other I hope. shouldn't show the bug
21:26 karolherbst: it's currently broken anyway
21:28 karolherbst: imirkin: and if you like: https://patchwork.freedesktop.org/series/12260/
21:28 karolherbst: not sure if it's _always_ 0x2f though
21:33 imirkin: i'd rather not merge something like that without deeper analysis
21:33 imirkin: i.e. wtf is 0x2f, etc
21:33 imirkin: coz i haven't the faintest clue
21:33 karolherbst: 0x20 is used for "normal" values
21:33 karolherbst: as a mask
21:34 karolherbst: and the lower bits are for the delay or so
21:35 karolherbst: in patchwork: "This account is inactive." :(
21:35 imirkin: =/
21:35 karolherbst: at least I got the password right
21:36 imirkin: ooh, i might be an admin
21:36 imirkin: hold on
21:36 imirkin: ah no
21:36 imirkin: i'm a project admin, not a full admin
21:36 karolherbst: :/
21:36 karolherbst: who is an admin?
21:37 imirkin: dunno. i think Kayden
21:37 imirkin: probably damien_l
21:37 karolherbst: k, thanks
21:41 karolherbst: imirkin: I think I leave the RA bits out and mail them to the ML again, I also have a FMA patch to enable it for FMA as well
21:44 jamm: imirkin: i've applied your patch for pascal and ran make + make install on xf86-video-nouveau. What should I do to test this? The installed stuff is in a separate $NVD prefix folder
22:04 karolherbst: imirkin: I think the idea behind the old MAD 0x8 imm code was to add a constraint to RA so that for a MAD/FMA with limms in pre RA it guaruantees, that RA will generate it that way
22:11 imirkin: karolherbst: hmmmm ok. possible. i don't think that was ever implemented.
22:13 jamm: imirkin: rebooted my PC; couldn't get past the GNOME login for some reason. It does seem to log in, but then the login window pops back again. I removed the 01-module-path.conf I created from /etc/X11/xorg.conf.d and it works now. Although I'm guessing the nouveau which I compiled isn't used yet..
22:13 karolherbst: there is a comment: // requires src == dst, cannot decide before RA (except if we implement more constraints)
22:13 karolherbst: imirkin: fun thing: this 0x8 flag enables limms, so that's that
22:14 karolherbst: anyway, we should fix that soonish, cause it _may_ get triggered somewhere
22:15 imirkin: jamm: iirc you have to set more than just the module path
22:18 jamm: imirkin: i see, okay, will find out what they are
22:18 imirkin: jamm: well, check the xorg log
22:19 imirkin: jamm: i.e. what was wrong
22:21 karolherbst: imirkin: could you give me the URL to that piglit result site again?
22:21 imirkin: http://people.freedesktop.org/~imirkin/
22:21 karolherbst: thanks
22:24 karolherbst: running it without -1 :) but bens recovery stuff works very well as well
22:24 karolherbst: good work
22:27 jamm: imirkin: added device directive in xorg.conf and rebooted, seems to work now, but..
22:28 jamm: [ 3.539202] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
22:28 jamm: am i on the right one? or is this the old nouveau which came with my distro?
22:28 jamm: the 20120801 seems suspicious
22:28 imirkin: that's fine
22:29 imirkin: the year is basically random
22:29 jamm: imirkin: alright, if everything went well then i should be on your patch now
22:30 imirkin: jamm: cool. pastebin xorg log?
22:30 jamm: i don't seem to find it in /var/log, maybe it's located elsewhere..
22:31 jamm: found it
22:33 jamm: imirkin: http://pastebin.com/aUm6j6P0
22:33 imirkin: jamm: looks like you're using modeset
22:34 imirkin: [ 23.787] (EE) Unknown chipset: NV134
22:34 imirkin: [ 23.776] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
22:34 imirkin: [ 23.777] compiled for 1.19.2, module version = 1.0.13
22:34 imirkin: so ... yeah. not the latest version + patch
22:34 jamm: hmm, i'll have to re-look at the xorg configs again
22:35 jamm: thanks!
22:50 karolherbst: imirkin: did somebody cleared up with the piglit tests? cause I thought there are many more
22:50 imirkin: ?
22:50 karolherbst: it's just like 25k
22:50 imirkin: check the date :)
22:50 karolherbst: I thought there are like 60k in total
22:51 karolherbst: what date? I just updated yesterday or so
22:52 karolherbst: :O
22:52 karolherbst: we have piglit tests which produce OOR_ADDR
22:55 karolherbst: and running those textureGather tests produced a MEMACK_TIMEOUT
22:58 imirkin: the date on those tests
22:58 imirkin: test results*
22:58 imirkin: the piglit tests that produce OOR_ADDR really do test reading out of bounds of constbufs
22:59 imirkin: the MEMACK_TIMEOUT sounds a lot more quesitonable
23:15 karolherbst: guess I should run piglit with -1 then :/
23:16 karolherbst: fifo: PBDMA0: 00000002 [MEMACK_TIMEOUT] ch 5 [00bf8ce000 textureGather[5262]] subc 0 mthd 001c data 00000002
23:16 karolherbst: I guess nouveau doesn't like tons of textureFather tests at once
23:21 imirkin: you should let skeggsb know
23:21 imirkin: he made wild claims about fixing all those
23:21 imirkin: or do you not have his various fix-patches?
23:21 imirkin: (or perhaps the wild claims were related to recovery)
23:21 karolherbst: I have those
23:22 karolherbst: and the wild claims were related to recovery
23:30 karolherbst: imirkin: mhh, but why should those out of bounds test generate dmesg warnings?
23:32 karolherbst: especially because not all of them do
23:33 karolherbst: only those with uniforms do.. for obvious reasons
23:38 karolherbst: I don't know how expensive those fault handlings are on the GPU
23:38 karolherbst: maybe worth to find out, because I somehow thing that this is the case for hitman (engine does silly things)
23:39 karolherbst: imirkin: how can I know in codegen, that an access to global memory is out of bounds?
23:40 karolherbst: I want to add a second level of verification inside handleLDST in nvc0 lowering
23:49 karolherbst: imirkin: should "spec@arb_tessellation_shader@execution@barrier" also generate an OOR_ADDR error?
23:49 karolherbst: same for spec@arb_tessellation_shader@execution@barrier-patch