02:02 Satchelboi: imirkin: Do you have any preference on what I should name the enum function?
02:25 dboyan_: Satchelboi: just curious, what are the values of each enum be? contiguous values starting from 0, or the same with our current notation, e.g. SM_30 -> 0xE4, SM_35 -> 0xEA
02:25 dboyan_: s/are/will
02:28 imirkin: Satchelboi: which enum function?
02:29 Satchelboi: imirkin: The one delcaring the SMxx versions, where the #define used to be
02:30 imirkin: i feel like i've typed my preferred enum definition like 5 times already...
02:30 Satchelboi: dboyan: I just kept them at what I was given. I can paste them in if you want to see what each one is
02:30 imirkin: enum sm_isa { SM10, SM20, SM30, SM35, SM50 }
02:35 Satchelboi: dboyan: https://paste.fedoraproject.org/paste/On4jBXVwv8YJpOrzt-Jovl5M1UNdIGYhyRLivL9gydE=/
02:38 dboyan_: Satchelboi: okay. Pay attention to the indentation though. Also you can add a "GF100" comment after SM20. Not sure about how to comment SM10. "G80" maybe?
02:39 Satchelboi: dboyan_: Indents were fixed. I'll in that comment for SM20 and double check on SM10
02:39 Satchelboi: Other than that, its about read to submit
02:42 imirkin: i'd recommend comments like // Tesla, // Fermi, etc
02:43 imirkin: although i guess it gets subtle around SM35
02:43 dboyan_: well, GK110 = Kepler gen 2
02:45 imirkin: right
02:45 imirkin: hence "subtle" but not impossible :)
02:47 dboyan_: imirkin: Do you know about PIPE_QUERY_SO_OVERFLOW_PREDICATE? It has been there since 2011, but seems never really used
02:47 imirkin: see ARB_tranform_feedback_query_overflow
02:48 imirkin: (ext name is approximate)
02:48 imirkin: i believe it's recently gotten an implementation in mesa
02:48 dboyan_: yeah, it somewhat matches that
02:48 imirkin: the issue is that the ext wants to be able to have it per stream, as well as globally
02:48 imirkin: it's unclear to me how to do it globally
02:48 imirkin: esp in the context of ARB_query_buffer_object
02:49 dboyan_: nvidia has a query for it actually
02:49 imirkin: per-stream, yea
02:49 imirkin: but not across all streams
02:49 dboyan_: SELECT = 0x1e, globally
02:49 dboyan_: on my gp107
02:49 dboyan_: didn't test on previous hw
02:49 imirkin: hm ok. well that's news to me
02:49 imirkin: that said, lots i don't know about queries :)
02:51 dboyan_: I don't know about queries in detail either, and I can't wholely understand the interactions there. Especially about conditional rendering
02:51 imirkin: meh, those bits all work :)
02:51 Satchelboi: imirkin: I can make the comments that then ^^
02:51 Satchelboi: I originally only had them there while I was replacing the chipsets so I remembered which ones were which
02:52 imirkin: dboyan_: i would also not exclude the possibility that SO_OVERFLOW_PREDICATE is either misimplemented or got broken over the years
02:53 dboyan_: yeah, different drivers have different interpretations on that
02:53 imirkin: nothign uses it, so it's kinda wtvr :)
02:53 dboyan_: softpipe treats it as a global flag, it seems
02:56 dboyan_: so the first step if we want to implement the ARB extension is to make two separate queries and make the sematics clear :)
02:57 imirkin: dboyan_: well, softpipe doesn't support multiple streams
02:58 imirkin: that only comes with ARB_gpu_shader5 (part of GL 4.0)
02:58 imirkin: the trick is that you need to be able to ask for both the indexed variant and non-indexed variant
02:58 imirkin: you could maybe feed in index == -1 for the non-indexed kind? dunno.
02:59 airlied: imirkin: softpipe sould support multiple stream
02:59 imirkin: airlied: really? ok. that's news to me.
02:59 imirkin: airlied: it doesn't support ARB_gpu_shader5 though right?
02:59 airlied:is pretty sure I wrote it at some point
03:00 imirkin: (if only someone had made a handy page to tell which driver supported which exts...)
03:00 imirkin: (oh wait, i did! https://people.freedesktop.org/~imirkin/glxinfo/ )
03:00 imirkin: airlied: no ARB_gs5 for llvmpipe/softpipe
03:00 airlied: maybe I never finished it :)
03:01 imirkin: it's been known to happen...
03:01 airlied:has a softpipe_gpu_shader5 branch :)
03:02 imirkin: without MS, at least the gl_SampleMaskIn bit of ARB_gs5 is a little amusing...
03:02 imirkin: and all the sample interp
03:02 dboyan_: ah, the multiple stream thing is in gs5.
03:02 airlied: I think that's where I bailed on it
03:03 airlied: and really needed tessellation for anyone to actual care
03:03 dboyan_:digged into ARB_tfb2 and ARB_tfb3 with no avail
03:04 imirkin: dboyan_: yeah, they all kinda work in tandem... but gs5 is the one that makes streams a thing
03:04 imirkin: tfb3 allows them to be sent to various buffers, iirc
03:04 imirkin: and enhanced_layouts makes it all a lot more configurable iirc
03:04 imirkin: or at least easier-to-configure
05:31 Satchelboi: I'll bite: I've been trying to figure out how to send my final patch as a reply to the first one, but I have no idea how to get the Message-id of the first one I sent out to reply to
05:38 imirkin: don't worry about that
05:39 imirkin: waste of time, imo
05:45 Satchelboi: Alright, I'll send it out like normal then
05:46 dboyan_: well, it seems tomorrow is mesa 17.1 branch point
05:47 Satchelboi: Is that big?
05:49 dboyan_: Satchelboi: Is it based on your previous one?
05:49 Satchelboi: dboyan_: It was, it was an improvement on that
05:50 Satchelboi: I already sent it out after that, just ignoring it
05:51 dboyan_: umm, I personally think it better to squash them into one commit.
05:52 dboyan_: but you can wait for karolherbst or imirkin's advice
05:53 Satchelboi_: dboyan_: I put them into the same commit I did the last changes and pushed that out, so its a complete package now
05:55 dboyan_: Satchelboi_: Also, one piece of advice here. Each line of commit message normally doesn't exceed 74 characters
05:57 dboyan_: My vim does it automatically when I'm using "git commit"
05:57 Satchelboi_: Whoops, I didn't realize I'd passed that
05:58 Satchelboi_: I edit my commits in a vim, so I thought it would do that part for me
05:58 dboyan_: Pay attention to that later :)
05:59 Satchelboi_: Is there a config I can set up so it'll cut to a new line every 74 characters?
06:01 dboyan_: it seems setting "filetype indent plugin on" in .vimrc helps
06:01 dboyan_: at least my vim will automatically wrap lines when I type commit messages
06:03 Satchelboi_: I'll set that then so I won't screw up the formatting for next time
06:08 imirkin: Satchelboi_: btw, it's Johannes Kepler, not Keplar.
06:08 imirkin: [just noticed that after sending my review]
06:11 dboyan_: imirkin: If sm_isa is left to default, then there should be a function to init it from chipset?
06:11 imirkin: i'd like for chipset to go away
06:11 imirkin: but it's unfair to make satchelboi do all of the proper work for that
06:13 dboyan_: imirkin: Another thing, do you want my ballot series go before his change? It seems 17.1 branch point is coming
06:13 imirkin: erm.... right. and you did send an updated series. let me take a looksie...
06:13 imirkin: i knew i was forgetting something!
06:14 dboyan_: and nvc0's emitSHFL has a chipset check
06:14 imirkin: that sort of thing is pretty minor and easily fixed either way
06:15 dboyan_: yeah, sure
06:21 imirkin: ok, this looks good enough to me... a few minor items, but not really worth fixing. (the setPDSTN api isn't *quite* what i had in mind, but functional)
06:23 dboyan_: well, there are some options for setPDSTL
06:24 dboyan_: I picked one I think reasonable, there are other reasonable ways though, some might be even better
06:25 imirkin: the one you did is fine
06:25 imirkin: i personally would have moved the i->defExists() logic into the function
06:26 imirkin: so like setting d = x and !i->defExists(d), then i'd consider that to be same as the -1 case
06:26 imirkin: but like i said... wtvr...
06:26 imirkin: i'm going to push as-is
06:27 dboyan_: okay, thanks
06:36 imirkin: dboyan_: tests/spec/arb_shader_ballot/execution/fs-builtin-variables.shader_test
06:36 imirkin: that fails for me (GK208)
06:37 imirkin: Observed: 255 2 2 0
06:37 imirkin: oh. that's because the test is broken. right. we discussed that.
06:37 dboyan_: yeah, exactly
06:38 imirkin: did you send a patch?
06:38 dboyan_: I haven't yet
06:38 dboyan_: but I have verified locally that the result is right
06:39 imirkin: k
06:45 imirkin: dboyan_: pushed, thanks a lot for doing the work :)
07:52 ccaione: soooo, any idea about https://bugs.freedesktop.org/show_bug.cgi?id=100446 ?
09:13 leberus: karolherbst: I've sent the patch but split this time :)
09:13 karolherbst: leberus: thanks, will take a look whenever I got time
09:19 leberus: thanks :)
09:26 leberus: karolherbst: last e-mail is a a duplicated from PATCH [1/4], just ignore it :). My mutt screwed it up xD
11:22 mekeor: when the nouveau driver hasn't been loaded, my laptops fan starts running, it starts beeping and after ~45 seconds, it shuts down. – unless i do `modprobe nouveau`. this even happens when i am in BIOS (where ofc nouveau isn't loaded). my laptop has optimus. – any idea why this happens?
11:42 mupuf: mekeor: terrible vbios/bios?
12:19 gnarface: mekeor: terrible bios or maybe don't block the exhaust port?
12:24 mupuf: gnarface: I doubt this would be that problematic
12:24 mupuf: mekeor: check if you can update your bios
12:24 mupuf: or vbios (more likely the problem, here)
12:25 gnarface: mupuf: if it's like sitting on a bed on top a thick quilt or something, it could really be a problem with some models
12:25 mupuf: 45 seconds? In the bios? Let's not push it :s
12:25 gnarface: ok, 45 seconds is a bit fast yes
12:25 gnarface: i'll agree with that...
12:25 gnarface: 45 minutes on the other hand
12:26 mupuf: yep, that could be. But nouveau does no power management
12:26 mupuf: aside from spinning fans on desktop pcs
12:27 karolherbst: Fans are controlled by the EC on laptops anywy
12:27 karolherbst: *anyway
12:27 mupuf: fan*
12:27 karolherbst: well, there could be two...
12:28 karolherbst: mhhhhhhh
12:29 karolherbst: sounds like a silly vbios to me
12:29 karolherbst: I guess some scripts need to be excuted which set up such things. Most likely the "I am too hot" GPIO of the GPU is triggered and notifies the system, that it doesn't feel well
14:16 dboyan_: Satchelboi: I want to remind you that my ARB_shader_ballot series got pushed today, and it has a chipset check. So you have to include that one in your next version.
14:18 Satchelboi: dboyan_: I thought the point of what I was doing was to get rid of the chipset checks
14:19 Satchelboi: Wait I see it now, never mind
14:20 dboyan_: It's just an easy one
14:25 karolherbst: Satchelboi: it would be good if you post a squashed version (via git rebaise -i or other means) with the added ISA field. then you just need to assign the value where also chipset gets assigned accordingly. The getChipset method has to stay for now
14:29 Satchelboi: karolherbst: So all get getIsa( ) have to go back to getChipset( ) ?
14:30 karolherbst: no
14:30 karolherbst: most are fine
14:30 karolherbst: ilia commented on the wrong ones
14:30 karolherbst: but you need to keep the getChipset method in the class
14:30 karolherbst: and use a new isa field for getISA
14:30 karolherbst: "inline uint32_t getChipset() const { return chipset; }" stays
14:30 karolherbst: add a new method for getISA
14:31 karolherbst: and return the enum value directly there
14:31 dboyan_: and don't forget to initialize the isa field
14:32 karolherbst: exactly
14:32 karolherbst: and then the patch will be how it should be and can be merged asap
14:35 mekeor: shit, i missed the discussion on my issue. thanks tho
14:36 Satchelboi: karolherbst: I did see the comment for the wrongly placed one, that will be reverted in the next version
14:36 karolherbst: yeah, just merge all the commits into one
14:37 Satchelboi: Karolherbst: So wait, did what I send last night only have what I changed since the first patch? I thought I'd already merged the commits when I sent it
14:38 karolherbst: yeah, you didn't send a merge of all commits
14:38 karolherbst: well
14:38 karolherbst: "sqaush" is the right term
14:38 karolherbst: with "git rebase -i origin/master" you should get a list of all commits you've written
14:38 karolherbst: leave the first as edit
14:39 karolherbst: all others as squash
14:39 karolherbst: or fixup
14:39 karolherbst: then you get one commit with everything
14:40 Satchelboi: Oh dear, yep they're both there.
14:41 dboyan_: well, "git rebase -i" is often useful
14:42 Satchelboi: I fix what was broken, squash them and submit the next revision, hopefully before my first lecture
14:42 Satchelboi: I'll*
14:43 Lyude: Is there a way to get any piglit test to output the results to a PNG file
14:44 Lyude: ah wait, this would be a better question for #dri-devel...
14:49 dboyan_: Lyude: One possible (but cumbersome) way is to apitrace the test, you can surely get png there
14:50 Lyude: dboyan_: ah, I was kind of hoping for something that would possibly let me do something like run piglit tests headlessly
14:51 karolherbst: Lyude: you can putput into html
14:51 karolherbst: ohhh
14:51 karolherbst: you meant the content
14:51 karolherbst: .... ask mupuf he does stuff like that
14:51 dboyan_: piglit *can* be run headlessly, though
14:51 Lyude: karolherbst: yeah
14:52 Lyude: mupuf: ^ ?
14:52 Lyude: would be a more elegant solution then constantly taking screenshots with my chamelium, lol
14:53 karolherbst: Lyude: he will tell you to use ezbench :p
14:53 dboyan_: there seems built-in png writing support in piglit
14:54 karolherbst: Lyude: he wrote software, which can automatically bisect stuff in mesa. Also changes in output
14:54 karolherbst: so if you want to go pro with this, ask him about his project :p or join #ezbench
14:55 dboyan_: Lyude: try -png argument
15:00 Satchelboi: dboyan_: You wanted me to change any remain getIsa( ) after the fixes to getISA( ) too, right?
15:00 karolherbst: getISA looks better
15:01 dboyan_: yeah
15:09 dboyan_: Lyude: No idea if you saw my message above, pitlit does have a "-png" argument that dumps png
15:10 dboyan_: *piglit
15:11 imirkin_: for headless, one tends to use gbm. (PIGLIT_PLATFORM=gbm .) that one has libcaca output capabilities, which is neat.
15:11 imirkin_: i generally just run in X, then use xwd to grab the window, then convert to png :)
15:11 imirkin_: old habits die hard
15:11 Lyude: dboyan_: oh no I didn't, but that looks like it might be what I need
15:13 karolherbst: Lyude: mupuf wrote a software called "ezbench", which can automatically bisect changes in the rendering output, if you need something like this as well at some point
15:23 Lyude: dboyan_: where did you see that --png argument?
15:27 dboyan_: Lyude: piglit-framework-gl.c
15:29 dboyan_: https://cgit.freedesktop.org/piglit/tree/tests/util/piglit-framework-gl.c#n123
15:30 Lyude: dboyan_: oh awesome that works perfectly, thanks!
15:37 Satchelboi: dboyan_: I have everything fixed except that last comment you made, I'm not quite sure how to add in the ISA and check they both work properly
15:39 dboyan_: Satchelboi: sorry but I didn't quite get what you are speaking
15:39 Satchelboi: dboyan_: Actually that was my mistake, it was imirkin that said that, not you. I was looking at the wrong name in the email
15:40 Satchelboi: imirkin_: I guess I need your help with that last bit now then
15:41 imirkin_: what did i say?
15:41 imirkin_: i couldn't sleep last night, and then had to get up early this morning, so ... my brain is a bit mush. help me out here :)
15:42 Satchelboi: The last comment, you wanted me to leave the chipset check but add in isa and a check for them both. I can't say I know really how to do that
15:43 imirkin_: Satchelboi: there should both be an isa, which is the enum thing, and the chipset, which is what it is today
15:43 imirkin_: i'm not sure what the question is.
15:43 Satchelboi: How do i add in the isa with the chipset?
15:44 karolherbst: Satchelboi: new field inside the class
15:44 karolherbst: and a new method
15:45 imirkin_: isa != chipset
15:45 imirkin_: isa is a whole separate thing
15:45 imirkin_: so add a new field, and then set it in nv50_program.c/nvc0_program.c
15:45 imirkin_: (and nouveau_compiler.c iirc)
15:45 Satchelboi: I learned that as I went down changing back things I shouldn't have changed, haha
16:23 RSpliet:goes and be pedantic - find it weird we refer to the (micro)architecture as a set of chips
16:24 imirkin_: RSpliet: yeah i'm trying to move away from that
16:24 imirkin_: but i want to make the change that Satchelboi does be reasonable given his knowledge of all the details
16:52 jam__: hakzsam: in https://cgit.freedesktop.org/~hakzsam/mesa/tree/src/gallium/drivers/nouveau/codegen/lib/gm107.asm?h=gm107_scheduler&id=6a4503026525246b9330da2b08e2caa71a963a5b#n14 why set all wt bars?
17:12 jam__: i'm having a hard time figuring out how ipa works. afaics it's one of OP_LINTERP/OP_PINTERP but the grammer is a still a mystery. The last two operands seem like indices to the interp/sample.. am i in the right direction?
17:13 jam__: s/grammer/grammar
17:28 pmoreau: jam__: It’s waiting for all operations using a barrier to finish, I would guess to be able to reuse those barriers for other operations.
17:29 pmoreau: Though, it doesn’t seem like all barriers are used in gm107_div_u32, so maybe it should only wait for the ones it is planning to use?
18:52 pmoreau: What is the size of the immediate on a ldg/stg instruction?
18:55 karolherbst: mhh in envydis is no imm form afaik
18:55 karolherbst: maybe check the cuda tools
18:55 pmoreau: By immediate, I mean LDG.E R4 [R6+0x10000], for example
18:56 pmoreau: Maybe offset would be a better choice
18:56 karolherbst: yeah
18:57 karolherbst: 20 bits as it seems
18:57 karolherbst: or 24?
18:58 pmoreau: Is the offset shifted somehow? If not, I have an example with at least 21 bits.
18:58 karolherbst: then 24
18:58 pmoreau: How do you find that information in envydis? I am looking at gm107.c for example
18:58 karolherbst: NCGMEM
18:58 karolherbst: = { "ncg", 0, &reg08_r, &smem_imm };
18:58 karolherbst: smem_imm = { { 20, 24 }, RBF_SIGNED };
18:58 karolherbst: first seems to be position, second size
18:59 karolherbst: the F32_20 imm constant is { { 20, 32 }, RBF_UNSIGNED };
19:00 pmoreau: … Thanks Github… The code window is taking only a 1/3 of the screen, but it can’t expand the code window to show the full line, you have to horizontally scroll… :-/
19:00 karolherbst: :D
19:00 karolherbst: yes
19:00 karolherbst: it's silly
19:01 karolherbst: but all good code is only 80 chars wide :O
19:01 pmoreau: True
19:02 pmoreau: Thanks for the pointer, now I need to understand how to parse all those structures in envydis :-D
19:05 pmoreau: So, that clears out why my trick didn’t work as expected: the offset was too large to fit in the 24 bits, so it had to add it to the register containing the address first.
19:40 xen: hi
19:41 xen: i've switched to the drm-next branch, after boot, no output on any displays
19:41 xen: https://pastebin.com/Ex4WMuuC
19:41 xen: here's the log i was able to scrub via ssh
19:44 Lyude: imirkin: regarding those post_depth_coverage tests, I just noticed the "simple multisampling test to check wehtehr or not the values written to gl_SampleMaskIn are still correct after enabling the ARB_post_depth_coverage extension." in the git description. We sure that test can actually be adjusted to check whether or not that extension just works? seems like it's written to check for a specific bug case
19:44 Lyude: instead of whether or not the extension actually works
19:45 Lyude: there's still some stuff in this extension I don't entirely understand but other then the sample count fix, these tests do at least look like they're doing what they're meant to do. although they're not very useful for actually testing whether or not the extension works.
19:52 pmoreau: xen: Which GPU is it?
19:52 pmoreau: xen: And do you have a way to get the full log, cause the one you linked wrapped around. :-/
19:53 imirkin_: Lyude: poor phrasing in the test i guess
19:53 imirkin_: Lyude: ARB_post_depth_coverage's sole purpose in life is to adjust the value of gl_SampleMaskIn
19:55 xen: pmoreau: lspci | grep VGA
19:55 xen: 01:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1070] (rev a1)
19:55 xen: 05:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 770] (rev a1)
19:55 xen: both
19:55 xen: pmoreau: i'm looking into the dmesg stuff now
19:56 pmoreau: If you only have one or the other plugged in, does that happen?
19:56 xen: hm.. haven't tried that
19:57 Lyude: imirkin_: poor wording meaning "that test is not nessecarily supposed to fail if ARB_post_depth_coverage was disabled?", or poor wording meaning the test does need to be fix
19:58 imirkin_: Lyude: poor wording as in the git description was worded poorly.
19:58 pmoreau: xen: So, it’s the GP104 which is unhappy. Maybe you are missing the firmware to operate it? Though, it shouldn’t get that upset if that was the case.
19:58 imirkin_: Lyude: if the implementation of ARB_post_depth_coverage is broken, that test should fail.
19:59 imirkin_: Lyude: it's kinda like when people write commit descriptions like "fix test xyz" when they really mean "fix implementation as pointed out by test xyz"
19:59 xen: how do i get the full log from dmesg?
20:00 Lyude: ah
20:00 xen: pmoreau: the unhappy one is me :) it did work for some time with the 770 and a 710 though
20:00 Lyude: funny enough, I purposely tried breaking the arb_post_depth_coverage support in i965 to see if the test would fail and it still passes
20:00 Lyude: this doesn't feel like it was tested very well...
20:01 pmoreau: xen: If you have journald, you should be able to retrieve it using `journalctl -b 0`. Otherwise, I think /var/log/messages will have wrapped as well.
20:01 pmoreau: xen: Eh eh! That’s what you get for trying shiny new hardware! :-p
20:02 xen: i was able to make it work with the nvidia blob, but no offload rendering magic with that :\
20:03 pmoreau: xen: Do you have a folder gp104 in /usr/lib/firmware/nvidia?
20:05 xen: ls gp104/
20:05 xen: acr gr nvdec sec2
20:05 xen: no graphics related log in journalctl log :(
20:06 pmoreau: So you should have the firmware
20:06 pmoreau: Try running journalctl as root, otherwise it will only show the logs from the services running as your user, it seems.
20:07 xen: oh wow
20:07 xen: i'm new to this kernel-graphics-magic stuff
20:08 Lyude: it's much nicer then the old ways
20:08 Lyude: ye ol' ums
20:10 xen: pmoreau: may i send you the log in PM?
20:11 imirkin_: Lyude: it's a little tricky to test =/
20:11 imirkin_: it requires being very careful about how you draw stuff
20:11 imirkin_: 99.999% of the time, the answer in gl_SampleMaskIn is the same as it would have been otherwise
20:11 pmoreau: xen: Ok; but other people might want to have a look as well
20:11 imirkin_: Lyude: basically you have to have samples that are covered but rejected by the depth test, but there are still lit fragments within the pixel so the frag shader runs.
20:12 imirkin_: Lyude: the easiest way to do it would be to create a cooked depth texture
20:12 Lyude: What do you mean by "lit"?
20:14 xen: sec, log too big for pastebin :\
20:15 imirkin_: <Lyude> What do you mean by "lit"?
20:15 imirkin_: <imirkin_> fragments that are not discarded
20:15 imirkin_: <imirkin_> so ... let's start simple. do you feel like you understand rasterization?
20:15 imirkin_: [stupid internet]
20:16 Lyude: imirkin_: I understand what rasterization is and what it does at the very least, I think. I know it turns fragments into pixels as one of the final stages of the pipeline
20:16 pmoreau: xen: You can cut after it starts spamming too many times the same error.
20:16 xen: did just that
20:18 Lyude: darn, i'm wrong, the internet says fragments are produced by the rasterizer :(
20:46 imirkin_: Lyude: ok, so ... let's say you want to draw a triangle
20:47 imirkin_: you have the vertices
20:47 imirkin_: and you map them into "window space" (i.e. pixel coordinates, basically)
20:47 imirkin_: but ultimately you have to figure out which pixels are "on" and which are "off"
20:48 imirkin_: i.e. you have a bitmapped surface (a raster, if you will)
20:48 imirkin_: and you have to figure out which pixels are covered on that raster and which are not
20:48 imirkin_: some will be fully covered, some will be partly covered (on the edges
20:49 imirkin_: but a pixel may either be covered or not. iirc the rule is that it's covered if the center is within the triangle.
20:49 imirkin_: then you get into MSAA. without going into the reasons for why this is a good idea, instead of looking at the center, you "sample" each pixel at multiple points (the samples, creatively named)
20:50 imirkin_: so you look at which samples are covered, and record that information
20:50 imirkin_: (aka a "coverage mask")
20:50 imirkin_: but you can still execute your pixel shader just once
20:50 imirkin_: and each sample will get the color in question
20:50 nyef`: More accurate when multiple triangles are semi-covering the same pixel?
20:51 imirkin_: nyef`: yes, basically for blending.
20:51 imirkin_: but with MSAA (without SSAA), each sample gets the same color
20:51 imirkin_: aka each fragment
20:51 nyef`: Mmm. And also plausibly more accurate when there's an alpha component?
20:51 imirkin_: nyef`: blending is quite configurable.
20:52 imirkin_: ok, so, now, to the meat of the issue
20:52 imirkin_: the rasterizer determines which samples are covered
20:52 imirkin_: this is based on the geometry of the triangle
20:52 imirkin_: after that, there's a so-called "depth test"
20:52 imirkin_: the depth test looks at the (surprise, surprise) depth attachment
20:53 imirkin_: and compares the depth of each fragment to the value in the depth attachment
20:53 imirkin_: if the depth test fails (based on the depth function, of which there are several), then the fragment is not considered covered for output (i.e. it's discarded)
20:53 imirkin_: SO
20:53 imirkin_: you have a difference between the samples that are covered by the tri and the samples that are covered after the depth test
20:54 imirkin_: ARB_post_depth_coverage controls whether gl_SampleMaskIn contains the coverage pre- or post-depth test.
20:54 imirkin_: ("the coverage" is a bitmask of the covered samples)
20:55 imirkin_: [btw, there are also other fragment tests, and i've skipped a bunch of details. trying to make this explanation shorter than the length of the GL spec itself]
20:58 xen: https://bugs.freedesktop.org/show_bug.cgi?id=100676
20:59 pmoreau: skeggsb: -^ the display part seems to hang during initialisation on a GP104 using drm-next for a couple of hours ago. Any ideas?
21:18 Lyude: imirkin_: okay, I'm slowly starting to get this
21:18 imirkin_: so sample-shading is SSAA - that's where the frag shader is run for each sample
21:18 imirkin_: (or for a group of samples)
21:19 imirkin_: but basically without MSAA, this is pointless - the coverage is always "1" because if the coverage were 0, your frag shader wouldn't run in the first place
21:20 imirkin_: and with sample shading run at full rate, i.e. one frag shader per sample, again the coverage of that one invocation (which is what's in gl_SampleMaskIn) will always have just 1 bit set
21:20 imirkin_: so my idea for a good test
21:20 imirkin_: is to make a multi-sampled depth texture, clear it to, say, 0, and then set sample 0 of each pixel to 1
21:21 imirkin_: and then draw a polygon that fully covers this thing, and ensure that gl_SampleMaskIn & 1 == 0 with post-depth coverage, and ==1 without post-depth coverage
21:22 imirkin_: and the way to only set sample 0 of this depth texture
21:22 imirkin_: is to again, draw a fully-covered polygon (at the proper depth), and set gl_SampleMask = 0xfe or whatever, which controls the *output* coverage mask
21:22 imirkin_: (or rather, gl_SampleMask = 1)
21:22 imirkin_: there's also a glSampleMask() which i don't fully remember how it works
21:23 imirkin_: that might actually be simpler :)
21:23 imirkin_: http://docs.gl/gl4/glSampleMaski
21:23 imirkin_: i never fully grok'd this stuff tbh
21:24 imirkin_: (like wtf glSampleMask and glSampleCoverage do... but you just set them in the hw, and the hw does what the tests expect, so all's well)
21:29 imirkin_: sorry if that was a bit long-winded, but this stuff's a bit subtle =/
21:30 Lyude: imirkin_: no that's fine, this makes a lot more sense then everything else I've read today. Thank you for taking the time to help me understand all of this btw
21:30 imirkin_: np. always happy to inform.
21:31 imirkin_: eventually it starts to become helpeful to think about "well, how would i solve this problem" (of e.g. drawing a triangle on a bitmap), and then all of a sudden the crazy GL stuff starts to make a bit of sense :)
21:34 Lyude: yeah, I've found trying to draw out text descriptions of this stuff on a whiteboard helps make things make a lot more sense
21:34 Lyude: this makes me miss having a tablet built into my laptop
21:38 imirkin_: yeah, so obviously explaining this stuff in person is a lot easier since it does tend to involve some drawing
21:38 imirkin_: eventually you'll start realizing that barycentric coordinates are actually a really good idea, and not just there to annoy you.
21:39 imirkin_: but i didn't properly understand that stuff until i hacked on swr and fixed some bugs in their logic
21:40 mupuf_: Lyude: how about using gbm as a backend?
21:42 Lyude: mupuf_: worked just fine, except for some particular tests which unfortunately happen to be the ones I'm working on
21:42 Lyude: (arb_post_depth_coverage)
21:47 mupuf_: what the heck?
21:47 mupuf_: why doesn't it work :s
21:50 imirkin_: Lyude: oh, also when working remotely, i tend to run a x11vnc session against the target X server =]
21:51 imirkin_: often an ARM board sitting on my desk
21:52 Lyude: mupuf_: not entirely sure, haven't bothered to look into it
21:53 Lyude: imirkin_: huh
21:53 imirkin_: so like run X + x11vnc on the "target" board, and then use vncviewer to connect to see wtf is going on
21:53 imirkin_: not ideal, but usually good enough
22:04 Satchelboi: imirkin_: You need the final patch from me by today, right?
22:05 imirkin_: i don't need anything from anyone. i'm not sure what the gsoc xorg project requirements are, but you should :)
22:06 Satchelboi: The final deadline is April 16th for the patch. It's almost done, I'm still just stuck on the last bit
22:07 imirkin_: ok, well, note that i don't have infinite amounts of time
22:08 imirkin_: i'll do my best to review promptly
22:10 Satchelboi: Luckily there isn't much there since the last version I sent, just some reversions and cosmetic fixes
22:10 Satchelboi: I just need to finish it off, which is taking longer than expected
22:21 RSpliet: leberus: you the hwmon guy? Sorry if I made some wrong assumptions about your git-fu, I should have checked your linkedin profile *before* sending the e-mail to the ML O:-)
22:23 karolherbst: well the series is kind of borked anyway
22:23 mupuf_: wait, hwmon finally reworked their internals to be accessible from the kernel space?
22:23 karolherbst: both 1/4 patches are different
22:24 karolherbst: mupuf_: odd, huh? :D
22:24 mupuf_: my god, 2017 IS the future!
22:24 karolherbst: :\o/
22:24 mupuf_: I remember bitching seriously about it in ... 2012
22:38 karolherbst: heh
22:39 karolherbst: I guess slowly more and more drivers actually want to use this
22:47 mjg59: I remember writing a patchset in 2009
22:51 mupuf_: mjg59: yep, we built on it!
22:51 mupuf_: only took 8 years then!
22:53 mjg59: Progress