00:01 pendingchaos: is it reasonable to assume that GL_MAX_SUBPIXEL_PRECISION_BIAS_BITS_NV is 8 on GM200 and later after finding it is 8 on GM204 and GO106?
00:08 imirkin_: yes
00:12 imirkin_: pendingchaos: if you want to look at sample patches to add support for an ext, search for my (very old) patches to add EXT_polygon_offset_clamp
00:12 imirkin_: that covers the displaylist bits too...
00:14 imirkin_: e.g. mesa commit 81998dda637cea18b1ec035e178dd829ce7e8645
00:15 pendingchaos: thanks
00:16 imirkin_: (and a few surrounding commits)
00:16 imirkin_: wow. 2014. so long ago.
00:23 imirkin_: pendingchaos: btw, you may have to come up with some piglit tests for this. let me know if you need help.
00:27 pendingchaos: thanks
03:14 loonquawl: How is Nouveau's performance with the gtx 1070? I can't seem to find anything online.
03:17 gnarface: i'm not sure they ever got it working
03:43 imirkin: loonquawl: no reclocking, so you get base clocks + working acceleration
03:43 imirkin: base clocks are often like 10% of max clocks
03:48 imirkin: gnarface: accel works on all released GPUs (except GV100)
04:50 loonquawl: Yeah I noticed I was having weird tearing issues on certain textures with OpenMW.
04:50 imirkin: loonquawl: there are also a bunch of non-descript "rendering issues" on maxwell+
04:51 imirkin: apparent in xonotic and unigine valley and i think heaven too
04:51 loonquawl: imirkin: I see. Thanks mate.
04:52 imirkin: if you want a good experience with open-source drivers, stick to AMD or Intel
04:52 loonquawl: Yeah I should have gone AMD, but I bought this graphics card at a time where I wasn't extremely informed on FOSS.
04:53 imirkin: "next time"
04:53 loonquawl: :)
04:54 imirkin: iirc someone was complaining of crashing issues with openmw + nouveau? i forget exactly
05:03 loonquawl: I don't understand why Nvidia doesn't release the source code for their drivers instead of a just a binary.
06:07 imirkin: pmoreau: dunno if you've already done it, but i located all the H* opcodes in the sm60 isa
06:08 imirkin: still need to do some flag triage
06:08 imirkin: like wtf is R0.H1_H1...
06:08 imirkin: i guess use the high word of R0 for both halves...
08:28 pmoreau: imirkin: Nice! Beside my small experiment some time ago to see how some of those half opcodes work, I haven’t looked at it since.
10:19 karolherbst: imirkin: most of the failing tests on the gk107 are big shaders doing spilling :( and I got less fails on a gk208...
10:59 pendingchaos: how should I expose conservative rasterization is Gallium? should I tailor it for NV_conservative_raster, have it support different styles (eg. NV, INTEL) or do something like how Vulkan does it?
11:00 pendingchaos: (how vulkan does it: https://pastebin.com/GL1mc9BN)
11:39 karolherbst: imirkin: weird... I get a different result when running on gdm vs glx post optimizations
11:40 karolherbst: before that everything seems to be identical
11:41 karolherbst: glx: mov u32 %r848 c0[0x0] (0); mov u32 %r849 c0[0x4] (0)
11:41 karolherbst: gbm: ld u64 { %r848 %r849 } c0[0x0] (0)
11:41 karolherbst: superweird
11:41 karolherbst: ld u32 %r848 c0[0x0]; ld u32 %r849 c0[0x4] before opts for both
11:48 RSpliet: tagr: before I praise your work on Tegra support, may I point out that the "tegra: Initial support" imports a tegra_drm.h file with a copyright header 2012-2013.. insignificant, but now I'm curious whether the code really is 5 years old :-P
11:49 RSpliet: That being said, nice one. I *really* want to try using the full OSS stack on the TX1 some time... when time permits
11:49 RSpliet: (when seems to slowly transition into "if" at the moment unfortunately)
12:17 karolherbst: imirkin: *sigh*, the issue is spilling indeed, but for a super weird reason
12:18 karolherbst: imirkin: on gdm the regs are limited to 62 on maxwell and then it pushes a quad value to be spilled and the unspiller doesn't apply the correct offset for zw components
12:18 karolherbst: huh.... wait a second
12:20 karolherbst: it uses always the first nvidia GPU?
12:22 karolherbst: imirkin: okay yeah, with gbm always the first nvidia GPU is picked up :( super annoying
12:35 karolherbst: and this also explains the difference after opts
14:41 imirkin: karolherbst: GBM_DEVICE iirc tells it which device to use. i forget.
14:42 imirkin: maybe it's WAFFLE_GBM_DEVICE if you're using waffle
14:42 karolherbst: ahh, maybe
14:42 imirkin: also you should be careful... gbm != gdm
14:42 karolherbst: yeah
14:42 karolherbst: I meant gbm :)
14:42 imirkin: lastly, unspilling should work fine in that case. unless you have special patches.
14:42 karolherbst: not quite sure
14:42 karolherbst: will take a deeper look after the weekend
14:57 tagr: RSpliet: the tegra_drm.h header is indeed that old, no (significant) changes happened after 2013
14:59 imirkin: pmoreau: i just did a brute-force fuzz of the top 13 bits of the instruction in nvdisasm and have those results, so i know where the opcodes are.
15:00 imirkin: pendingchaos: ideally you'd do things that aren't nvidia-specific. so even if only (some) nvidia chips can do it, it shouldn't have NV in the name anywhere.
15:00 imirkin: pendingchaos: support_xyz is handled with PIPE_CAP_FOO
15:01 imirkin: so it's mostly going to be a matter of the dynamic parameters. based on past observations, the vulkan stuff is reasonably well thought-out, so wouldn't necessarily be a bad thing to emulate.
15:02 imirkin: you might also ask mareko and nha in #radeon to inform yourself on the AMD device capabilities, ideally to create an interface that works for everyone
15:22 pendingchaos: looking at https://gpuinfo.org, i'm not sure if AMD devices support conservative rasterization, but i'll ask anyway
15:39 imirkin_: pendingchaos: well, those are just extensions ... who knows what the hw supports.
15:39 imirkin_: AMD's not always good at making their more esoteric hw features available
15:42 imirkin_: either way, asking is pretty cheap :)
17:19 Rucha: Hello @imirkin, this is about the 'fix fbo blending formats task'. I have understood how to go about these 3 steps: 1. compile nouveau over GPU 2.install mesa 3.run glxgears to make sure how it works. Could you please guide for the further steps?
17:21 Rucha: Also, there are so many fermi GPUs I am confused which to go for. Could you suggest anything in particular?
17:39 imirkin_: Rucha: for that bug, doesn't matter which gpu you have
17:39 imirkin_: Rucha: tbh i don't remember your original questions...
17:40 imirkin_: i have the attention span of a goldfish... if it happened more than 24h ago, you can safely assume i don't remember.
17:43 Rucha: Actually I am working on the "Fix FBO blending formats" task and I had asked you from where to start. So I have understood the compilation of nouveau over Fermi GPU, install mesa and run on glxgears to make sure it works.
17:44 imirkin_: almost any nvidia gpu for that particular issue, really
17:44 Rucha: Could you brief me about how to go about the actual problem statement
17:44 imirkin_: perhaps there was some other reason a fermi gpu was interesting?
17:44 imirkin_: it's described in the trello board
17:44 imirkin_: https://trello.com/c/YnhHNblO/100-nv50-nvc0-fix-fbo-blending-formats-glrgb10
17:45 imirkin_: that should explain everything you need
17:45 imirkin_: if you have very concrete questions, happy to answer. i don't really have time to provide a full class on ... GPUs.
17:48 Rucha: All right, thank you
17:55 grische: Is it possible to over/underclock or -volt a card with nouveau? If yes, how?
17:56 imirkin_: depends on the card
17:57 imirkin_: for cards where reclocking is supported, just supply a vbios with the desired pstates, nouveau should be able to operate them
17:57 grische: Is there some tool to edit vbios'?
17:58 imirkin_: i think there's stuff people use on windows
17:58 imirkin_: i'm not really familiar with it though
17:58 imirkin_: and i have no clue how it works -- there's a ton of stuff one has to get right, or else it all fails
17:59 grische: So there is no open source tool for vbios editing? Do you know the structure of the vbios?
17:59 imirkin_: the parts of the vbios that we parse, sure.
18:00 grische: According to your trello you linked above, it seems that Pascal has no reclocking support at the moment.
18:00 imirkin_: correct.
18:01 grische: Can you give me some pointers on where to find the vbios structure?
18:02 imirkin_: https://github.com/envytools/envytools/tree/master/nvbios
18:02 imirkin_: https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/subdev/bios
18:02 imirkin_: and the recently released http://download.nvidia.com/open-gpu-doc/BIOS-Information-Table/1/BIOS-Information-Table.html
18:03 grische: Is the latter already in envytools / nouveau?
18:03 imirkin_: i believe someone went through and updated nvbios with some of that
18:03 grische: nice. Thanks!
18:04 imirkin_: the stuff in nouveau is the stuff that's used, so nothing to really update
18:17 orbea: Does this apitrace render anything other than a black screen for anyone? http://ks392457.kimsufi.com/orbea/stuff/trace/retroarch_beetle_psx_blackscreen.trace.xz
18:20 imirkin_: orbea: intel hates it for some reason
18:21 imirkin_: 4171 @0 glAttachShader(program = 33, shader = 931371435)
18:21 imirkin_: 4171: warning: glGetError(glAttachShader) = GL_INVALID_VALUE
18:21 imirkin_: that seems ... bogus.
18:21 orbea: yea, I got this https://pastebin.com/fsU7jejG
18:22 imirkin_: ah, that's different - you're getting a compat profile instead of core
18:22 orbea: not sure when it started, cant find a good commit in retroarch or the emulator...
18:22 orbea: strange
18:22 imirkin_: (or it started assuming it could have a GL 3.3 compat profile)
18:23 orbea: maybe something in mesa changed?
18:23 imirkin_: conceivable
18:24 imirkin_: but unlikely.
18:36 orbea: doesn't seem to be retroarch or the emulator and other emulators using the core profile work still...guess I should check mesa next.
19:22 grische: orbea: radeonsi also gives me plenty of errors with the trace
20:20 orbea: something is really wrong here, the issue vanished and now it just crashes, nothing has changed...
20:57 orbea: crashes were a corrupter mesa shader cache...
20:58 orbea: *corrupted
22:10 pendingchaos: I think I've mostly got GL_NV_conservative_raster done
22:10 pendingchaos: the tests are mostly finished but I'm not sure if their code quality is good enough
22:10 pendingchaos: also, how conservative rasterization is exposed in gallium needs to be finalized
22:22 imirkin_: do they pass on nvidia, and fail when you comment out setting the CONSERVATIVE_RASTER bit?
22:23 imirkin_: if so, you're done.
23:02 pendingchaos: I've fixed a problem with the point rasterization tests making with pass with conservative rasterization disabled
23:03 pendingchaos: the results of a few tests seem to differ between the blob and nouveau. Looking and the differing images, I think it might be precision errors
23:03 pendingchaos: *looking at
23:04 pendingchaos: so I think I'll try to make the vertices less sensitive to precision
23:16 imirkin_: pendingchaos: hm, surprising that they'd differ. some other rast setting different? i noticed that 0xa08 was also set by the blob in a trace, while we don't set it
23:16 imirkin_: pendingchaos: also, i wonder if that setting is per-viewport in hw. the api in the ext appears to be across viewports though.
23:16 imirkin_: (i.e. ARB_viewport_array viewports)
23:17 imirkin_: er, make that 0xa18
23:22 imirkin_: pendingchaos: btw, while you have the RE setup, you might as well figure out where the params live for the other NV_conservative_raster_* exts
23:22 imirkin_: one of them includes a shader param... that will most likely be a quesiton of figuring out which special register it's in, or alternatively what input it comes in as
23:28 pendingchaos: They seem to also differ when conservative rasterization is not enabled
23:29 imirkin_: odd.
23:30 pendingchaos: it's probably because I deliberately made the vertices rather sensitive to precision
23:30 pendingchaos: so I could test glSubpixelPrecisionBiasNV
23:30 imirkin_: yeah, but ... it's the same hw. hard to imagine what's different =/
23:38 pendingchaos: the effect is that of a few vertices moving slightly downwards; is there much malnipulation of positions in a passthrough vertex shader?
23:39 imirkin_: should just be shoving data around
23:39 imirkin_: that's why i'm confused ...
23:39 imirkin_: it's something odd
23:39 imirkin_: like a "weird" rasterization setting that's different
23:39 imirkin_: are you running the piglit with -fbo?
23:40 imirkin_: if it's winsys, i think there are some very minor differences in how the flip is performed which perhaps could account for this?
23:44 pendingchaos: I'll try that
23:45 imirkin_: i gtg, good luck