08:36karolherbst: nice, some flickering issues in a game
09:19karolherbst: uhh, texture doesn't get drawn, weird
09:21karolherbst: but a frame earlier it got
11:03npnth: Hi, I've got a machine that appears to be leaking memory in the kernel.
11:03npnth: If I let it sit for a week or so, I end up with 6G of memory in SUnreclaim (according to /proc/meminfo), which according to slabtop is from 'kmalloc-64'.
11:03npnth: (In particular, it's *not* from 'ext4_inode_cache' or anything like that.)
11:03npnth: The memory isn't owned by any process - I can kill everything down to X and crond without significantly affecting memory usage.
11:03npnth: The above makes me think this is in the kernel. The most obscure thing I run is nouveau, so I figured I'd ask:
11:03npnth: Are there any known memory leaks with nouveau right now? If so, great, I can stop looking and wait for a fix. If not, I'll keep looking.
11:28karolherbst: npnth: well, it could be everything
11:29karolherbst: and if we would know about any leaks, we would try to fix it
11:30npnth: Sure, of course. But perhaps somebody found a leak a month ago and is trying to track it down, and there isn't a fix yet, but people know that there's a problem.
11:31npnth: That's the situation I'm hoping for, because then I can stop trying to figure out what the results of "perf" mean, and which project I can even go to with my bug report.
11:31karolherbst: well, not that I know of
11:31npnth: Fair enough - thanks then!
11:31karolherbst: and I doubt you will be able to figure it out with perf
11:31npnth: Personally, I doubt that I'll be able to figure it out at all :)
11:31karolherbst: maybe there is some kind of kernel memory leak detector... maybe not, I never looked into that
11:32pmoreau: imirkin_: NVC0LegalizeSSA::handleShift assumed the shift would not be an immediate but didn’t check for it. I added a handleImmShift version as you can simplify things a bit when you know the immediate.
11:38karolherbst: pmoreau: nice
11:40pmoreau: I have no idea how I did not hit that code path before, since those transforms are at the very least two years old :o
11:40karolherbst: the order of opts sometimes matters
11:41karolherbst: and many of the opts depend on that order
11:41karolherbst: like early opts might not check for mods
11:43RSpliet: karolherst.npnth: you can configure slab with leak detect functionality. Can't tell you exactly how that works...
11:47npnth: RSpliet: I'm currently reading up CONFIG_DEBUG_KMEMLEAK, which might be what you mean. That's OT, I guess, but if I find something concrete I'll let people know.
11:47RSpliet: DEBUG_SLAB_LEAK is the one I thought of, perhaps KMEMLEAK is more useful/relevant
11:50npnth: RSpliet: That sounds good, too. I'll try it.
12:34pmoreau: karolherbst, imirkin_: Do you think it is better to have it like this https://hastebin.com/orujikewuj.php or include the imm handling in the existing handleShift function?
12:37pmoreau: Or even call the handleShiftImm function from within handleShift.
12:44karolherbst: pmoreau: usually it is easier to handle that in one function
12:48pmoreau: karolherbst, imirkin_: If within the same function, it gives something like this: https://hastebin.com/kabimokani.diff
12:49karolherbst: try to be smarter ;)
12:49pmoreau: Minus the assert at the beginning. :-D
12:49karolherbst: the OR instruction is bascially the same in both cases
12:50pmoreau: Only one arg changes, true
12:50pmoreau: And it does not have a predicate
12:50karolherbst: but mhh
12:51pmoreau: So I am going to have if/else blocks all over the place inside that code (almost).
12:51karolherbst: maybe a different approach
12:51karolherbst: if you shift by more then 32 bits, you can simplify that to a 32bit shift eintirely
12:51karolherbst: I mean a shift by x-32
12:52karolherbst: and you need to set something to 0 I think
12:53pmoreau: The low bits of dst should be zero in that case.
12:55karolherbst: yeah, something like that
12:55karolherbst: you just shift the low bits by x-32 into dst.hi and set dst.lo to 0
12:57pmoreau: That’s what’s happening (minus the dst.lo being set to 0).
12:57karolherbst: you shift the src.hi into dst.hi, right?
12:57karolherbst: or what is src?
12:58pmoreau: src[i] is src.hi
12:58karolherbst: ahh, okay
12:58pmoreau: Oh right, I see what you mean.
12:59karolherbst: you confused me :O
13:00pmoreau: Ah, but the srcs are swapped if it’s a SHR.
13:00karolherbst: ohh, I see
13:01pmoreau: I *think* the original code is partly wrong.
13:16pmoreau: Yes, there is an error: The operation after `Compute HI (shift > 32)` should be using src and not src.
14:09NSA: appearently i somehow killed my gpu
14:10NSA: at least the driver
14:10karolherbst: NSA: rebooting should help in every case
14:10NSA: i was wondering if there's any way to avoid that
14:10karolherbst: try to find the cause
14:11NSA: it's spamming my journal with plenty of this: https://paste.debian.net/plainh/ff87f901
14:11NSA: once per second
14:11NSA: just the ch3: psh line is changing
14:11karolherbst: is there something before that?
14:12NSA: system froze before that for about an hour due to oom
14:12karolherbst: I think imirkin might know what is going on here
14:12NSA: then it was back responding for a few seconds
14:12NSA: and after that it froze again
14:12NSA: i was able to ssh in though
14:12NSA: and it's responding just fine
14:12NSA: just the display is frozen
14:13karolherbst: I think it might be the bug where something spawns too many requests and we run out of space in the fifo or something like this
14:13karolherbst: but maybe there is some initial error in the log
14:16NSA: https://gist.github.com/Nothing4You/392eb93e8dfab7e48b41a173ac680d1a this should be where it started
14:17karolherbst: that out of memory doesn't sound good to begin with
14:21NSA: yeah, i've been running oom every once in a while - been thinking about adding some swap, however, i'll have to repartition my ssd for that
14:21karolherbst: you could swap to zram
14:22karolherbst: zram is basically compressed memory, which you can use as a swap device
14:22karolherbst: it is still inside RAM, but compressed
14:22karolherbst: some people get around 2x memory with this
14:22karolherbst: but there is a performance hit, which you also have by swapping to a disc ;)
14:22karolherbst: just not as bad I figure
14:22karolherbst: especially if you compare it with a HDD
14:23karolherbst: I use zram for swap and tmpfs replacement
14:23NSA: luckily i don't use hdds in my desktop anymore
14:23NSA: only for storage via lan
14:23karolherbst: well swapping on SSD should be still slower though, maybe not with those pcie nvme ones
14:24NSA: yeah but it's far better than hdds
14:24karolherbst: allthough I would argue that swapping to a ahci ssd is also pain, because you block other disc IO
14:24NSA: wait what
14:24NSA: it just fucking recovered
14:24karolherbst: sometimes it does
14:24NSA: i just waited long enough and it is back
14:25karolherbst: well, nouveau tries to reset the state and move one
14:25karolherbst: sometimes it works, sometimes it doesn't
14:25karolherbst: and sometimes it just needs a lot of time
14:25NSA: i think i just wasn't able to use my pc for about 1.5h due to problems originating with the OOM
14:26karolherbst: how much RAM do you have?
14:26karolherbst: that should be plenty...
14:26NSA: that's what people keep telling me
14:26NSA: yet i run into oom like once or twice in 2 months
14:27karolherbst: I usually max around 12GB
14:28karolherbst: maybe you should keep an eye open and check which application might eat so much RAM, allthough that isn't really easy in some cases
14:28karolherbst: or maybe it is also inside the kernel, where some memory leak detection might figure that out
14:30NSA: probably not happening often enough to "easily" figure that out
14:31karolherbst: or run with 16GB, should speed it up :p
14:31NSA: and i wouldn't be surprised if it was closed source software causing those issues
14:31NSA: like in this instance it was the steam web helper that was oom killed
14:31karolherbst: steam web helper is basically chromium
14:31NSA: that doesn't mean valve is using it properly
14:32karolherbst: well, we don't know. Web browser tend to do a lot of allocation and deallocations and might just trigger the oom situation
14:32karolherbst: could be everything else needed so much RAM
14:32karolherbst: or leaking it
14:35NSA: i guess i should just go and add some swap soon
16:12imirkin: pmoreau: 64-bit shifts can't get an immediate arg merged in
16:12imirkin: pmoreau: pretty sure that canInsnLoad is set up not to allow that
16:13imirkin: pmoreau: on input into the IR, you should never have an immediate arg to a real (non-mov) op
16:14pmoreau: imirkin: I always have the immediates go through a mov first before being used.
16:15pmoreau: The issue is ConstantFolding folds an imm into MUL (or MAD) for the second operand. Then, turns out the imm is a power of two -> SHL.
16:15pmoreau: And you get an immediate as the shift value.
16:39imirkin: ahh =/
16:40imirkin: ok yeah, so then handleShift needs a bit of help
16:40imirkin: i did not anticipate that scenario.
16:41imirkin: (and we want the MUL to have the imm because that makes split64BitOps work better)
16:42imirkin: hopefully my comments were sufficient to explain wtf was going on
16:42imirkin: it *is* a bit subtle, esp the way i have the std::swap() in there ;)
16:43pmoreau: Also, there is a small error in handleShift: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp#n219 it should be src, not src, according to the comments earlier (and it works better)
16:43imirkin: i think one of you was saying i got the args backwards, but i doubt it
16:43imirkin: that said, it should be trivial to trigger any issues with a piglit test, so go for it
16:43pmoreau: Yeah, the double swap makes it a bit trickier.
16:44imirkin: "it works better"?
16:45imirkin: i.e. you found bugs in the existing logic?
16:45imirkin: what values does it not handle?
16:45imirkin: just make a shader_test, should be easy to prove
16:45pmoreau: Well, I get the same result as doing the same operation on the CPU.
16:45imirkin: for which values.
16:46pmoreau: That’s weird, that was for 1ull << 32ull
16:47pmoreau: But the predicate of that instruction should be false.
16:48imirkin: well, that clearly should be handled.
16:49imirkin: let's make a shader_test...
16:49pmoreau: If we consider a SHL, src == src0.lo and src == src0.hi, right?
16:50imirkin: i haven't looked at the code
16:51pmoreau: The comments says "(HI,LO) << x = (LO << (x - 32), 0)", so "HI = (LO << (x - 32))", but the code does "shl dst src x_minus_32", so "shl dst.hi src.hi x_minus_32"
16:51karolherbst: read the code ;)
16:53pmoreau: Let’s see if I can right a shader_test
16:53karolherbst: bld.mkSplit(src, 4, lo->getSrc(0));
16:53imirkin: pmoreau: https://hastebin.com/ifilefamod.cpp
16:53imirkin: does this fail for you?
16:53imirkin: it passes on SM35
16:54karolherbst: so I guess src is the hi value here, because it gets data.offset += halfSize applied
16:55pmoreau: imirkin: It skips :-/ You run it with shader_runner, right?
16:55imirkin: pmoreau: yes
16:55imirkin: it passes for me
16:55orbea: this shader commit for RetroArch just didn't work for me, no crash, just immediately closed. Couldn't even get an apitrace. Could there be something nouveau cant handle in it or is the problem more general? https://github.com/libretro/RetroArch/commit/bada13a2152b2092e7c66e656b06f14bcd8ea07c retroarch verbose output at least https://pastebin.com/WKVxw3TP
16:56imirkin: both with the SM35 code, as well as with the SM30 code
16:56feep: I'm a newb and I have no idea about the codebase, but ... shouldn't those be informatively named macros?
16:56feep: GET_HI, SET_HI and such
16:57karolherbst: feep: in a perfect world, yes
16:57imirkin: feep: writing a compiler can be subtle work.
16:57imirkin: figuring out wtf "hi" means in the first place can be tricky.
16:58pmoreau: imirkin: What are the arguments again to let it run and print the result, rather than displaying a window? It’s something with auto and fb, but I can’t get it right.
16:58imirkin: one could make single-use macros, but those tend to just obfuscate code more
16:58imirkin: pmoreau: -auto
16:58imirkin: pmoreau: green = good, not-green = bad.
16:58pmoreau: Ah, I was trying with double dash
16:59imirkin: pmoreau: also -fbo does off-scren rendering, but that doesn't really matter here
16:59imirkin: pmoreau: anyways, when you find a set of args that mess up that shader, let me know. until then i'm assuming that handleShift is OK :)
16:59pmoreau: imirkin: "./bin/shader_runner -auto shift.shader_test" could not read file "-auto" what did I messed up :-(
17:00imirkin: pmoreau: based on tests/spec/arb_gpu_shader_int64/execution/fs-shift-scalar-by-scalar.shader_test btw
17:00imirkin: filename first, options second
17:00karolherbst: pmoreau: put args after file
17:00pmoreau: Eh, ok
17:02pmoreau: It does pass as well, but the error is in the shfl > 32 code path.
17:04pmoreau: And if I change shfl to 33, and the result to 0x200000000, it does fail. Unless I change src to src.
17:04karolherbst: pmoreau: I am sure you are right here as well
17:05imirkin: pmoreau: ok. just test it out for all the various cases.
17:06imirkin: fwiw the SM35 path works ;)
17:06imirkin: not that that's surprising
17:06pmoreau: I couldn’t properly read my test: I had 1ull << 33ull in my test, not 1ull << 32ull as I previously said.
17:07karolherbst: ohh, imirkin I found an issue with some textures not being drawn in a few frames
17:07pmoreau: Anyway, will try the various test cases.
17:07karolherbst: I have a trace if you want to look at it
17:07karolherbst: I am sure your GPU can render that trace in under a minute
17:07karolherbst: well 30 seconds even
17:07karolherbst: I already tried MESA_DEBUG=flush, but that didn't do anything
17:08imirkin: pmoreau: lol ok.
17:08imirkin: pmoreau: just make sure it works with shr
17:08imirkin: add more swaps as necessar y;)
17:08pmoreau: Right, was going to try that
17:08imirkin: karolherbst: i can look, but i have ... no time
17:09karolherbst: imirkin: well, at least you can tell me if it happens on gk110
17:09pmoreau: I think there are enough swaps :-D
17:09karolherbst: or newer
17:09imirkin: well - GK208
17:09karolherbst: I tried to install it on my pascal one, but steam doesn't like my fedora or the other way around...
17:13karolherbst: imirkin: https://drive.google.com/open?id=19oejmug6I7yC9LVHlhYVaCW0VjvaDQDi
17:13pmoreau: 0x2ffffffff >> 33 == 1 currently fails, but succeeds if using src as well (which makes sense as src contains the high bits here, and we want those, not the low bits.
17:14karolherbst: call 959061 is correct on intel and wrong with nouveau
17:14karolherbst: pmoreau: write a patch
17:14pmoreau: karolherbst: Planning to :-)
17:14karolherbst: well, hopefully we have some piglit tests testing this
17:15karolherbst: pmoreau: you mean this src, right? https://github.com/karolherbst/mesa/blob/master/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp#L219
17:15karolherbst: yeah, that has to be src for sure
17:16pmoreau: Yes, that one
17:17karolherbst: weird though
17:17pmoreau: Going to run the various int64 piglit tests.
17:19karolherbst: x32_minus_shift is shift - 0x20, and the code wants to do src << -(shift - 0x20) basically
17:19pmoreau: Yep, which is fine
17:19pmoreau: Wait no, you mixed the first one
17:19karolherbst: I don't think so
17:19pmoreau: x32_minus_shift == 32 - shift
17:20karolherbst: ohh wait
17:20karolherbst: src(0) gets the -
17:20karolherbst: -shift + 32
17:21karolherbst: and then
17:21karolherbst: src << -(-shift + 32)
17:21karolherbst: which is src << shift - 32
17:22karolherbst: looks a bit like this is more complicated than it should be, but it seems fine though
17:22pmoreau: Right, but it avoids one operation.
17:59imirkin: karolherbst: 959061 in that trace is a glBindBuffer call
18:02karolherbst: ahhh, crap, I debuged a different trace I made
18:05imirkin: karolherbst: pmoreau: yeah, that clearly has to be src
18:05imirkin: since we want LO << something, and LO is in src
18:06imirkin: (finally got a chance to look at the code carefully)
18:06imirkin: feel free to add even more comments if you like
18:06pmoreau:should right shader_test more often
18:06pmoreau: The comments in the beginning are pretty good
18:07imirkin: it's pretty compact code
18:07imirkin: but it avoids having to have 4 semi-identical sections of logic
18:07pmoreau: Updating fs-shift-scalar-by-scalar.shader_test test to include shifts higher than 32.
18:07imirkin: er, 2 i guess.
18:08imirkin: yeah, good idea
18:08imirkin: shader_test's are pretty easy to write
18:08imirkin: there's a bit of boiler plate, but there's tons of examples
18:08karolherbst: imirkin: https://drive.google.com/open?id=1hqFiZEOp8hW5ayJju7aF9FV_fJjQzgEe
18:08imirkin: eventually you can do it all from memory
18:09imirkin: karolherbst: ok, that's a draw in this one. good start :)
18:10karolherbst: well there should be some path rendered on the bottom
18:10karolherbst: the one in the texture
18:10karolherbst: on intel it does get rendered
18:11imirkin: karolherbst: https://i.imgur.com/iosBj7F.png
18:11imirkin: i assume whatever's supposed to be there is missing?
18:11imirkin: this is with mesa 17.3.0-rc5
18:11pmoreau: True, setting up the same thing with OpenCL is a bit more involved. Plus it will depend on all my work, rather than just the regular code.
18:11karolherbst: imirkin: look at texture0
18:12imirkin: some black vase-looking thing?
18:12karolherbst: open it
18:12karolherbst: and flip it
18:13karolherbst: that is the same call on intel: https://i.imgur.com/zQaRx7X.png
18:13imirkin: oh i see
18:13karolherbst: replaying the trace you should see some flickering
18:13karolherbst: you can imagine that isn't right
18:14karolherbst: afaik some texture don't get drawn in calls like this one
18:14karolherbst: no idea why
18:15imirkin: i wonder if it's the bug i just fixed
18:15imirkin: hold on
18:16imirkin: no :(
18:16imirkin: but it was such a good idea
18:16imirkin: it's *exactly* the case that's broken
18:16imirkin: i.e. a mix() with a single-arg lerp param
18:17karolherbst: but it works with intel and llvmpipe
18:17imirkin: yeah. and it doesn't work with that bug fix in place. so it's not that issue.
18:17imirkin: but it's *close* to that issue ;)
18:18karolherbst: the sahders didn't look really special
18:18karolherbst: so I didn't really looked into those
18:18imirkin: gl_FragColor = mix( grey, tex0, Saturation);
18:18imirkin: and Saturation is a "uniform float"
18:18imirkin: i think in the tgsi, it comes out as CONST.xyzw
18:18imirkin: instead of CONST.xxxx
18:19imirkin: in practice, Saturation == 1.0
18:19imirkin: so the color should be 100% the texture
18:19karolherbst: okay, I could check that
18:20imirkin: but like i said, i don't think that's it
18:20imirkin: (also note that patch has a minor bug... should be oo.swizzle, not ->swizzle)
18:20karolherbst: I just noticed that there is MESA_SHADER_DUMP_PATH and MESA_SHADER_READ_PATH :)
18:21imirkin: there's another potential problem in that it's a GL_RGB framebuffer
18:21imirkin: and it's using blending
18:21imirkin: although GL_DST_ALPHA is never used...
18:21imirkin: which is the theoretically-problematic case
18:23imirkin: karolherbst: do try that patch, perhaps i have some other patch which is causing additional troubles
18:25karolherbst: ../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:1365:41: error: base operand of ‘->’ has non-pointer type ‘st_src_reg’
18:25imirkin: see above
18:26karolherbst: but mhh
18:26karolherbst: why does it work with llvmpipe then
18:27imirkin: i prefer not to ask such questions until i find out that the patch helps
18:27imirkin: if it helps - we can figure it out
18:27imirkin: perhaps we implement LRP differently
18:27imirkin: but if it doesn't, then don't worry and move on :)
18:27karolherbst: right, it doesn't help
18:27imirkin: ok cool
18:28imirkin: at least it's consistent.
18:28imirkin: ok. another thing going on here is that it's an elements draw with a small number of elements
18:28imirkin: it's conceivable that the push hint stuff logic is broken
18:29karolherbst: but that should happen every frame
18:29karolherbst: or well, the call should be kind of the same every frame
18:30karolherbst: except that the scene is a bit different
18:30imirkin: yep, doesn't help
18:30karolherbst: see call 953567
18:30karolherbst: same thing, just one frame earlier
18:32karolherbst: modelviewProjection has different values though
18:32karolherbst: which is an uniform in the fragment shader
18:32karolherbst: but uhm...
18:33imirkin: i gtg
18:33imirkin: good luck
18:33karolherbst: I will play around with that a bit
18:35karolherbst: uhm... vertex shader though
18:40pmoreau: imirkin: Does https://hastebin.com/yeweqanixe.md seems reasonable considering the input is https://hastebin.com/nojuyevume.cpp ?
18:40pmoreau: I don’t understand why there is no ISHR64.
18:44karolherbst: imirkin: okay, that uniform indeed changes the behaviour
18:44karolherbst: maybe we run into some precision issues here?
18:55karolherbst: 64bit int stuff
18:57imirkin: pmoreau: yes... quite reasonable ... there is both an I64SHR and U64SHR
18:58imirkin: pmoreau: only a U64SHL since sign doesn't matter for SHL
18:58karolherbst: here are the shaders: https://gist.github.com/karolherbst/660a390dea931e6c4d92a899d3ffa0f6
18:58pmoreau: Ugh, yeah, I missed the I64SHR --"
18:59imirkin: karolherbst: is that with my patch?
18:59imirkin: karolherbst: 10: LRP TEMP, CONST.xxxx, TEMP, TEMP
18:59karolherbst: ohh wait
18:59karolherbst: it might be
18:59imirkin: i think before it would do "CONST"
18:59karolherbst: no, it isn't
18:59imirkin: hm, oh well.
19:00imirkin: that's what i had in mind though about fixing
19:05imirkin: 23: sub ftz f32 $r4 $r3 $r3 (8)
19:05imirkin: 24: mad ftz f32 $r3 $r4 c0[0x0] $r3 (8)
19:05imirkin: should probably have some opt that sub (a,a) == 0
19:05imirkin: i guess it's not 10000% accurate, but it's *pretty* accurate
19:05imirkin: (since e.g. Infinity - Infinity = NaN, and NaN - anything = NaN)
19:05karolherbst: wait a second...
19:06karolherbst: oh no, should be fine
19:06imirkin: yeah. it's correct. both sides have tex.a as the arg
19:06imirkin: so a lerp between tex.a and tex.a will always give ... tex.a
19:06karolherbst: I am sure the issue is within that vertex shader though, or the matrix calculation ends up producing values the fragment shader can't handle
19:07pmoreau: imirkin: Could you please try this on your SM35? https://hastebin.com/piqakitora.cpp
19:09imirkin: i think i did a lot less testing on SM30
19:10imirkin: i basically just did it, then forced the lowering on my box, ran a couple tests and it was fine, so ... must be right
19:12pmoreau: No worries! Besides for OpenCL address computations, I don’t think int64 paths will be that used.
19:21karolherbst: imirkin: well, when I do gl_FragColor = tex0, I see basically the same issue
19:39karolherbst: imirkin: something is wrong with that matrix multiplcation, but I really don't know what
19:45karolherbst: mhh interesting
19:48karolherbst: okay, here is the deal
19:49karolherbst: imirkin: in this line: "gl_Position = modelviewProjection * vec4(vPosition, 1.0);" the application depends on modelviewProjection having -z <= w. but the inputs are always like z == -w
19:50karolherbst: so if I slightly increase w or slightly decrease z the issue kind of disappears
19:50karolherbst: and decrease z means * 0.99999... and increase w means * 1.000....1
19:51karolherbst: z being negative and w positive
19:51imirkin_: so it's getting clipped?
19:52karolherbst: well, might be
19:52karolherbst: in the shader, z should be c0[0x38] and w c0[0x3c], right?
19:53imirkin_: can't look now
19:53karolherbst: mhh, well in the end both values are parts of a matrix multiplcation into gl_Position
19:54karolherbst: this line: gl_Position = modelviewProjection * vec4(vPosition, 1.0);
19:56karolherbst: maybe some hw precision thing?
20:03tobijk: karolherbst: floar vs double in tgsi rep?
20:05karolherbst: I don't think those are actually doubles in any way
21:26Faults: karolherbst: Join #Solus-Chat where we can praise Solus and worship Ikey
21:46Lyude: Is the API for rnndb documented anywhere?
21:46Lyude: not entirely sure yet; but I might want to start hooking some stuff up from biopenly to rnndb
21:47imirkin_: not completely
21:48imirkin_: rob's been using it for freedreno, you can talk to him about his experiences with it
21:48imirkin_: eric went with the intel-made thing for vc4
21:48imirkin_: which is approximately the same as rnndb, but NIH
21:55karolherbst: I think etnaviv also uses some parts of envytools like rnndb
21:55imirkin_: ah yeah, they do
21:58karolherbst: how can I disable clipping in nouveau?
21:58karolherbst: well, if it can be disabled at all
22:28karolherbst: imirkin_: oh yeah, by disabling enough stuff which have "clip" in their names, the issue went away
22:29karolherbst: all my changes: https://gist.github.com/karolherbst/d75444fd2e0cc3a54ab160734e12fcdc
22:30karolherbst: I am sure it is the change in nvc0_state.c which helped
22:30imirkin_: my guess is that's the hunk that plays.
22:31karolherbst: that's the one
22:33karolherbst: imirkin_: adding NVC0_3D_VIEW_VOLUME_CLIP_CTRL_DEPTH_CLAMP_NEAR to the origina path helps
22:34imirkin_: i need to spend a few and properly RE that VIEW_VOLUME_CLIP thin
22:34imirkin_: unfortunately this can only be done with a proper understanding of clipping
22:34imirkin_: in practice, i only have like a 25%-complete understanding of clipping.
22:35karolherbst: and I verified that the other two flags don't change anyhting
22:37karolherbst: mhh, is clipping really that complicated or is it just like a priority kind of thing?
22:38imirkin_: the core concept is pretty simple.
22:38imirkin_: the problem is that various hw offers a wide variety of options for how its done
22:38imirkin_: and the various bits implement those variations
22:39imirkin_: knowing what variations are out there ahead of time sure helps :)
22:39imirkin_: like ... clamping, for example - that clamps the depth instead of clipping
22:39imirkin_: then there's depth vs x/y clipping
22:44imirkin_: is there a polygon offset that's set?
22:44karolherbst: how can I check?
22:45karolherbst: yeah well, how?
22:45imirkin_: glPolygonOffset() and iirc it should come out in the state
22:45imirkin_: like GL_POLYGON_OFFSET or something
22:45imirkin_: there's a few of them
22:45karolherbst: well right, but not for that call
22:46imirkin_: i mean - there are a few GL_POLYGON_OFFSET_bla's
22:46imirkin_: SCALE, FACTOR, and CLAMP probably
22:46karolherbst: they are set to default