12:18 manili: Hi all, Is there anybody who started developing Nouveau as a C beginner programmer and then became an expert developer? I have some questions to ask ...
12:19 RSpliet: manili: this is IRC. don't ask to ask, just ask
12:20 imirkin: all languages are pretty much alike... the differences are all in the syntactic sugar
12:20 imirkin: an experienced programmer who doesn't know C shouldn't have too much trouble
12:21 manili: @RSpliet: OK, Sorry. I'm newbie. I
12:22 manili: I'm reading some articles. But still cannot understand what's going on as a complete picture.
12:22 imirkin: 'complete' picture is all relative...
12:22 manili: What's different between DRI, DRM
12:22 imirkin: https://68.media.tumblr.com/tumblr_kxldz31eZQ1qaukck.png
12:23 manili: and is nouveau part of DRI
12:23 imirkin: nouveau isn't a single thing
12:23 imirkin: it's multiple separate but related pieces of software
12:24 manili: let's me see the pic first
12:24 imirkin: that was re getting a complete picture of something
12:28 manili: @imirkin: So nouveau is a software stack ?
12:30 karolherbst: imirkin: nice pie :O
12:31 karolherbst: manili: well I started as a C newbe on nouveau, but I am far from being an expert :p
12:32 imirkin: manili: mmm... more like graphics on linux is a stack, and nouveau (along with every driver) has a piece in every element of that stack
12:35 manili: @imirkin: So where the nouveau plays the role ? Is it something in DRM layer of this graphics stack ?
12:52 karolherbst: manili: everywhere
12:52 karolherbst: manili: there are several parts: kernel module, DDX and mesa as the big ones
16:15 tobijk: karolherbst: the shader you gave me yesterday for the cull error looks like it isnt the right one actually, how did you get your hands on that one?
16:15 karolherbst: tobijk: why isn't it the right one?
16:15 karolherbst: it causes that error for me
16:16 tobijk: you mean the assert?
16:16 karolherbst: yeah
16:16 tobijk: airlied fixed that one, but its not related
16:16 karolherbst: it caused a crash in a debug build
16:16 karolherbst: I know that the test still fails
16:16 karolherbst: but it doesn't crash anymore
16:16 tobijk: yep with the fix it is fine, stil lwe fail the test
16:16 karolherbst: which makes things easier to debug
16:16 karolherbst: yes
16:16 karolherbst: I know
16:16 tobijk: we do not see cull distances in one shader stage
16:17 karolherbst: no idea if I find time today to do other stuff than cleaning up my patch series from yesterday and cleaning up at home :D
16:18 tobijk: yeah np :)
16:19 tobijk: karolherbst: still how did you get your hands on the shader though? (it only has 2 shader stages with cull the "right one" has three)
16:19 karolherbst: it should has three
16:19 karolherbst: let me check
16:20 karolherbst: tobijk: this one right? https://gist.githubusercontent.com/karolherbst/24f83b4367231268d937c3b03a1d7bbb/raw/c590f4a3d8d7ff4a6770b6e9e5c7bc6c4ea1863c/gistfile1.txt
16:20 karolherbst: tobijk: I just got it from running it with intel and debuged what the shader name was
16:20 karolherbst: they all have numbers
16:20 tobijk: mh ok
16:20 karolherbst: 442 should be this one
16:20 tobijk: and no it looks like that one is the wrong one
16:21 karolherbst: you need a debug build
16:21 karolherbst: depending on what you actually test though
16:21 karolherbst: the failing test is something else
16:21 karolherbst: the test generated hundreds of shaders
16:22 karolherbst: *generates
16:22 karolherbst: so a different one is responsible for failing the test
16:22 karolherbst: anyway, gotta go
16:22 tobijk: yep and one has three shader stages with 8 cull distances, which are lowered fine, but the driver does not see the cul ldistances in one stage
16:23 tobijk: whoops
17:49 tobijk: imirkin: is it intentional to not assign cul ldistances to a tess ctrl shader? anyway karolherbst the test fail occurs when tesselation comes into play
17:50 imirkin_: err
17:50 imirkin_: hm.
17:50 imirkin_: no, it's not intentional
17:50 imirkin_: however they don't do anything if assigned in a TCS, except being readable from a TES
17:50 imirkin_: they don't actually cull/clip anything
17:51 imirkin_: and i do have to say, now that you mention tessellation specifically, i remember some kind of fail with clip distances and TCS+TES
17:51 tobijk: yeah maybe we do not do clip/cull right with tesselatio then
17:51 imirkin_: but i can't quickly find what it was
17:52 tobijk: np
19:24 airlied: karolherbst, tobijk : you have to assign the cull dist to the hw (not sure how nouveau does it) at the end of vertex/tesseval/geom, whichever is the final stage
19:24 airlied: so say writing them to the hw at vertex when you have tess would be bad etc
19:26 imirkin_: airlied: well, it also needs to be passed from stage to stage until the ultimate stage
19:26 imirkin_: e.g. VS can write it and then TCS can read it via gl_in.
19:26 imirkin_: airlied: unrelated: did you see my email about the index int16 -> int32 thing?
19:29 airlied: imirkin_: yes I did, and I wrote a patch, then did something else and forgot it
19:29 imirkin_: and here we are :)
19:29 airlied: https://paste.fedoraproject.org/paste/LP2avJCSHIogZAjt5ivxDA
19:29 imirkin_: someone needs to remove the shiny things from your work area :p
19:29 airlied: was my patch I believe
19:30 airlied: I think the something else was glsl distance lowering :-P
19:30 imirkin_: ah. i think there's a second spot too.
19:30 imirkin_: and if it's a uint16, you don't need the typecast on it anymore.
19:31 airlied: ah indeed sampler has one as well
19:31 imirkin_: anyways, that sounds good to me :)
19:32 karolherbst: airlied: didn't you push the patch to your git repository or do you have a new one?
19:33 airlied: don't think I pushed it anywhere, it has an r-b now so I'll push it to master now
19:33 karolherbst: ahh, okay
19:41 karolherbst: odd
19:41 karolherbst: if I want to run all the tests in external/openglcts/data/mustpass/gl/khronos_mustpass/4.5.5.x/gl30-master.txt, only 'KHR-GL30.info.vendor' is tested
19:42 karolherbst: with a "Test run was ABORTED!"
19:42 imirkin_: probably need to force GL 4.5
19:42 karolherbst: I get a "Mesa: User error: GL_INVALID_ENUM in glBindBufferARB(target GL_TEXTURE_BUFFER_BINDING)" though
19:42 karolherbst: imirkin_: I've patched mesa to expose 4.5
19:42 karolherbst: and it also happens on intel
19:42 imirkin_: heh ok
19:42 karolherbst: I am sure it worked yesterday
19:42 karolherbst: ....
19:43 karolherbst: same with a release build
19:43 karolherbst: well 31 runs, so this is good enough
19:44 karolherbst: "Passed: 32/42 (76.2%)"
19:47 karolherbst: I think I ignore everything with an "InternalError (Error)"
19:48 karolherbst: interessting: https://gist.githubusercontent.com/karolherbst/54b79fba054f5dc4071508149e4db7d9/raw/6ca1f7a1cdf8d51275b8f110a3ed30bd3f49162e/gistfile1.txt
19:49 karolherbst: it was run with requesting 4.2C
19:49 karolherbst: I do it the easy way now, just running those 44 and 45 tests
19:53 tobijk: imirkin_: mh well our TES after the TCS does see the cull distances again, not sure what is the right thing to do here (no clue how tesselation works :/)
19:53 imirkin_: tobijk: ok, well i haven't analyzed the issue at all (at least not recently), so not sure what the issue is.
20:00 karolherbst: what's up with that "KHR-GL45.texture_swizzle.smoke" test? it takes forever
20:01 airlied: it's having a smoke
20:01 airlied: some CTS tests do a lot of stuff
20:02 karolherbst: ohh, it's already at the next test
20:25 karolherbst: fun, imirkin_ you remember this one memory corruption? https://trello.com/c/PiazFevu/8-khr-gl45shadersarraysreturnfloatfragment-invalid-read
20:25 karolherbst: I managed to create an apitrace of that
20:25 karolherbst: guess what, running it with glretrace there is no memory corruption
20:27 pmoreau: The size member of the Storage class (Value->reg.size), contains the size in bytes, not bits, right?
20:27 karolherbst: pmoreau: I guess so
20:28 pmoreau: As the comment says "this should match the Instruction type's size", and `typeSizeof()` returns the number of bytes for a type.
20:30 pmoreau: Then the constant folding code for splits is wrong: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp#n941
20:31 pmoreau: And line 950
20:31 pmoreau: It should be (size * 8)
20:31 karolherbst: pmoreau: random thought or did you encounter a bug?
20:32 pmoreau: I did enounter a bug, where with a 64-bit immediate being split, I had only zeroes in the end
20:33 karolherbst: is it fixed with adding *8?
20:34 pmoreau: And, if you split a 32-bit values in 2 chunks (of 2 bytes each), you have a mask of 0xffff (1 << (2 * 8)) - 1, not 0x3 ((1 << 2) - 1)
20:37 pmoreau: It does work properly with adding a *8.
20:37 karolherbst: nice
20:37 karolherbst: nice catch
20:39 RSpliet: pmoreau: do you nicely lower that into a (1 << (2 << 3)) ? :-P
20:39 pmoreau: RSpliet: I let the compiler you uses to compile Mesa do that ;-)
20:40 pmoreau: The mask is not computed on the GPU, it is on the CPU.
20:41 RSpliet: :-D
20:41 karolherbst: pmoreau: thinking about this, shouldn't that cause a lot of errors already?
20:41 karolherbst: I mean, how lucky are we that it doesn't really affect much
20:42 pmoreau: Because I don’t think you split 32-bit -> 16-bit, nor 16-bit -> 8-bit values.
20:42 karolherbst: or is there something I miss and it should happen like never in normal use cases?
20:42 pmoreau: However, 64-bit -> 32-bit is probably more common.
20:43 karolherbst: aren't there a few computer shader around with 64bit calculations?
20:43 pmoreau: Probably
20:44 pmoreau: But 64-bit integers doesn’t seem to be that used.
20:48 RSpliet: not for any other purpose than pointer arithmetic?
20:49 pmoreau: It might be more used in CUDA/OpenCL kernels, than in OpenGL shaders.
20:50 pmoreau: It didn’t seem, from what I heard here or on the ML, that many applications use the 64-bit integer OpenGL extension.
20:55 RSpliet: It'd just degrade performance too much
20:55 RSpliet: I imagine this extension is more for Pixar and Dreamworks :-P
20:55 pmoreau: :-D
21:37 fitzgen: how should I go about debugging why `glxinfo` says I only have opengl 2.1, despite having a graphics card that supports opengl 4.5, and which is seemingly well supported by nouveau and mesa? thanks for pointers
21:37 imirkin_: fitzgen: --enable-texture-float
21:37 fitzgen: imirkin_: to what command?
21:37 imirkin_: ./configure
21:37 imirkin_: :)
21:38 fitzgen:goes to read source building instructions
21:38 imirkin_: chances are you can reuse your distro's build scripts
21:38 imirkin_: to build a final result that plays nice with your overall system
21:38 imirkin_: what GPU do you have btw?
21:39 Lyude: Anyone know what exactly this is for? https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/fb/ramgt215.c#L37
21:39 imirkin_: Lyude: for reclocking
21:39 Lyude: I know that, but moreso that struct specifically
21:39 fitzgen: imirkin_: GeForce 750 Ti
21:40 Lyude: like, for adding new reg writes there should I just add a ramfuc_reg struct for each one? or do I need to do more then just that
21:40 imirkin_: Lyude: it's the first arg to the ram_* functions
21:40 fitzgen: was recommended in here a few days ago
21:40 imirkin_: Lyude: those ram_* "functions" are actually clever little macros which do things like write to r_##arg1
21:40 karolherbst: Lyude: it's for the memory reclocking script ran on the PMU
21:41 karolherbst: or it is the script basically
21:41 imirkin_: fitzgen: yeah, should work mostly fine.
21:41 imirkin_: fitzgen: which distro?
21:41 Lyude: karolherbst: ahhh, btw: adding the blcg stuff we need to that
21:41 fitzgen: imirkin_: fedora
21:41 karolherbst: Lyude: why?
21:41 imirkin_: fitzgen: ah ... can't really help you, but should be able to grab their srpm and build it with the additional flag i guess?
21:41 Lyude: karolherbst: going according to the vbios mmio traces
21:41 karolherbst: Lyude: those things can usually also be done on the host, doing on the PMU is just for convenience
21:42 imirkin_: lots of redhat people in here who may be able to provide more concrete instructions
21:42 imirkin_: [i'm just not one of them]
21:42 Lyude: yeah I figured, but that seems to be around where I would think we'd want to write it. I will have to give you more info on this in PM since I have to point you to the vbios trace specifically
21:42 karolherbst: Lyude: well not only, there are some advantages on doing it on the PMU
21:43 fitzgen: imirkin_: thanks
21:43 Lyude: fitzgen: fedpkg -a clone glxinfo, or whatever the name of the actual package that contains that is
21:44 Lyude: add the stuff you need to the spec file, make an srpm, and rebuild with mock (ignore the wiki telling you to build it with rpmbuild, it's 2017 and rpmbuild is pointless to call by hand)
21:45 fitzgen: Lyude: I want to build nouveau from source tho (right?) not glxinfo; I could be wrong, but I thought glxinfo is just telling me my actual capabilities, it isn't itself my goal
21:46 Lyude: oh right, sorry, missed that part
21:46 Lyude: yeah, then just do the same thing but for mesa, there should be a line saying %configure in the srpm somewhere that you can add the option to
21:47 fitzgen: Lyude: thanks
21:47 Lyude: fitzgen: np, lemme know if you run into any issues
21:47 fitzgen: Lyude: will do :)
21:49 fitzgen: imirkin_: the configure flag is for mesa-libGL, or for nouveau, or? My understanding is that there are multiple parts here, but I don't have a great grasp on their boundaries/responsibilities
21:51 Lyude: fitzgen: srpms are lil confusing, lemme explain
21:51 Lyude: Basically the srpm itself builds only a single package, the extra packages you see defined in the spec are basically just made of files from the original package build
21:52 Lyude: so, build mesa package, create a bunch of subpackages containing some files, etc. that is what mesa-libGL is
21:52 Lyude: just ignore those, and look for the configure macro (if there is one, if not I might have to poke around and remember what that spec file does)
21:52 fitzgen: so in this case, I want `fedpkg -a clone mesa`? not `fedpkg -a clone nouveau`?
21:53 Lyude: yeah
21:53 fitzgen: thanks
21:53 imirkin_: fitzgen: sorry - it's for mesa.
21:53 fitzgen: np, thanks all for having patience with me :)
21:53 imirkin_: fitzgen: nouveau's not a thing as far as software packages go... just a piece of a bunch of diff software
21:54 fitzgen: got it
21:54 imirkin_: (kernel, libdrm, mesa... i guess there is a xf86-video-nouveau :) )
21:56 fitzgen: huh... mesa.spec *already* has `--enable-texture-float=yes` in the %configure
21:56 fitzgen: should I just continue making an srpm and rebuilding with mock?
21:57 pmoreau: Maybe missing the S3TC library package?
21:57 pmoreau: It’s called libtxc_dxtn on Arch, not sure for Fedora
21:58 fitzgen: installing
21:58 RSpliet: on Fedora you'll need to fish it from rpmfusion
21:59 fitzgen: `dnf install libtxc_dxtn` seemed to do the trick; am I missing something?
21:59 fitzgen: I think I already set up rpmfusion
22:00 pmoreau: Be aware that S3TC is patented (the patent is ending in like a year IIRC): https://fedoraproject.org/wiki/Forbidden_items#S3TC_Texture_Compression
22:00 fitzgen: pmoreau: so now that I have S3TC, what would the next steps be? glxinfo reports nothign different
22:01 tobijk: pmoreau: actually this year :)
22:01 pmoreau: And Mesa was already built with the --enable-float-texture flag?
22:01 pmoreau: tobijk: \o/
22:02 fitzgen: pmoreau: according to the fedpkg sources, yes (I have the most up to date mesa available on dnf, so I assume it matches)
22:02 imirkin_: s3tc won't matter
22:02 imirkin_: fedora might apply a patch
22:03 pmoreau: Oh right, s3tc matters when you run an application that uses it, but you do not have the lib installed, and you end up with missing textures
22:03 pmoreau: Or black ones
22:03 fitzgen: I see `--enable-gles2` on the configure line; gles >= 3 is what I am ultimately after
22:03 fitzgen: can I `--enable-gles3`?
22:03 imirkin_: won't matter
22:04 imirkin_: fitzgen: mind pastebinning the full output of 'glxinfo'?
22:04 fitzgen: sure thing, one sec
22:04 imirkin_: fitzgen: as well as your xorg log
22:04 imirkin_: [i have a theory i want to check out]
22:04 pmoreau: gtg
22:04 fitzgen: imirkin_: where is the xorg log?
22:05 fitzgen: pmoreau: thanks for the help!
22:05 RSpliet: fitzgen: hidden in journalctl. I never quite know how to extract that myself
22:05 tobijk: fitzgen: should be in /var/log
22:05 pmoreau: fitzgen: Let’s hope you can solve that issue :-)
22:06 pmoreau: RSpliet: Is it? I’ll have to look for that, but at least I still have it in /var/log.
22:06 imirkin_: it's in /var/log on reasonable systems
22:06 tobijk: heh
22:06 RSpliet: imirkin_: Fedora isn't reasonable
22:06 imirkin_: pretty sure that fedora & co have moved to the unreasonable train, so you're on your own
22:06 RSpliet: also, if this is F25, he's running Wayland
22:06 fitzgen: well, here's glxinfo: https://gist.github.com/fitzgen/b0d71e67a9e804b7ab3e831916bb542f
22:07 fitzgen: still looking for xorg logs
22:07 fitzgen: Yes, this is fedora 25
22:07 imirkin_: OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 256 bits)
22:07 imirkin_: heh
22:07 imirkin_: THAT is your issue :)
22:07 imirkin_: you're not using nouveau at all.
22:07 tobijk: impressive though: Video memory: 64317MB
22:07 fitzgen: ah
22:07 tobijk: :D
22:07 fitzgen: so... how do I start using nouveau? :-P
22:08 imirkin_: well ... it should Just Work (tm) so you need to figure out why that's not happening
22:08 imirkin_: pastebin dmesg + xorg log is a start
22:08 fitzgen: ok, brb
22:16 fitzgen: added dmesg output to https://gist.github.com/fitzgen/b0d71e67a9e804b7ab3e831916bb542f
22:16 imirkin_: nouveau does not appear to be loaded
22:17 imirkin_: nomodeset
22:17 imirkin_: that disables all graphics stuff.
22:18 fitzgen: `journalctl | grep X11`: https://gist.github.com/fitzgen/b0d71e67a9e804b7ab3e831916bb542f#file-journalctl-grep-x11
22:18 imirkin_: doesn't matter -- with nomodeset, none of the modern graphics drivers can operate
22:19 fitzgen: ok, so I need to edit my grub config?
22:19 imirkin_: also, that grep result is insufficient
22:19 imirkin_: based on it, i'm guessing grep gdm-x-session would be more fruitful
22:19 imirkin_: or using a system which isn't actively user-hostile... but i digress.
22:20 fitzgen: ok, rebooting, brb
22:24 fitzgen: \o/ https://www.irccloud.com/pastebin/qNB1RUCI/
22:24 imirkin_: huzzah
22:25 fitzgen: imirkin_: thanks!
22:25 imirkin_: and actually you should have GL 4.5, we just don't advertize it
22:25 fitzgen: imirkin_: very appreciated
22:25 fitzgen: ah cool
22:25 imirkin_: but if some application/game needs it, you can force-enable it
22:25 fitzgen: I think the app is just checking for gles >= 3
22:25 imirkin_: also you should be able to reclock your GPU to get better performance when you need it
22:25 fitzgen: sweet
22:25 imirkin_: check /sys/kernel/debug/dri/0/pstate
22:26 imirkin_: it's just manual reclocking, but you can echo the various levels into that pstate file to change between states
22:26 imirkin_: off chance you need 4.11 for that for GM107, not 100% sure.
22:27 RSpliet: but 4.11 should be only a dnf update away
22:27 karolherbst: 4.11 it is indeed
22:28 fitzgen: neato