IRC Logs of #dri-devel on for 2015-10-09

Previous dayChoose dateNext day Show menu

00:15 #dri-devel: < EdB> Horrorcat: want to try piglit CL test?
00:44 #dri-devel: < j4ni> airlied: I've failed at harassing people to review any potential fixes, so no, I have no pull req for you this week :(
00:45 #dri-devel: < danvet> j4ni, there's a few I pinged you on with r-b already attached ...
00:45 #dri-devel: < danvet> or at least I thought they had r-b attached already
00:47 #dri-devel: < j4ni> ...and degenerated into yes-no-maybe later with no clear conclusion
00:47 #dri-devel: < danvet> :(
00:47 #dri-devel: < j4ni> ...and my fail for not harassing people to come up with the conclusion
00:49 #dri-devel: < j4ni> okay, there's at least one that's progressed last night, but I wouldn't send a pull request on the day I apply fixes
03:59 #dri-devel: < Horrorcat> EdB: I could, where do I get those?
04:02 #dri-devel: < EdB> Horrorcat:
04:04 #dri-devel: < EdB> Horrorcat: You can restrict the build to the opencl tests framework
04:16 #dri-devel: < linkmauve1> When I iterate over the planes listed in the drmModePlaneResPtr returned by drmModeGetPlaneResources(), I only get three planes instead of the nine I get when I iterate over the entire range of the possible plane_ids, is there something I’m missing?
04:16 #dri-devel: < linkmauve1> These seem to be only the DRM_PLANE_TYPE_OVERLAY ones.
04:20 #dri-devel: < wCPO> How do I check if i'm using direct rendering?
04:22 #dri-devel: < wCPO> Stupid me.. Just need to look at the top of glxinfo
04:33 #dri-devel: < pq> linkmauve1, forgot to set the CAP for universal planes?
04:35 #dri-devel: < pq> linkmauve1, DRM_CLIENT_CAP_UNIVERSAL_PLANES
05:24 #dri-devel: < linkmauve1> pq, thanks, I was missing that cap.
05:45 #dri-devel: < aboll_> xexaxo: could you cherry-pick 70e91d6 for the next 11.0.x stable release?
05:55 #dri-devel: < Horrorcat> hm, EdB
05:55 #dri-devel: < Horrorcat> clpeak does not find any platforms
05:55 #dri-devel: < EdB> Horrorcat: ?
05:55 #dri-devel: < Horrorcat> ah
05:56 #dri-devel: < Horrorcat> I need LD_LIBRARY_PATH
05:56 #dri-devel: < Horrorcat> now it does
05:56 #dri-devel: < Horrorcat> how to run piglit now?
05:57 #dri-devel: < EdB> ./piglit run cl ./results/cl_test
05:57 #dri-devel: < Horrorcat> there is no piglit binary
05:57 #dri-devel: < Horrorcat> oh, there is a script in the repository
05:58 #dri-devel: < EdB> yes a python
05:58 #dri-devel: < Horrorcat> there we go
05:59 #dri-devel: < Horrorcat> it does things
05:59 #dri-devel: < Horrorcat> one fail and one skip already
05:59 #dri-devel: < Horrorcat> I’ll let you know when it’s done
05:59 #dri-devel: < Horrorcat> looks like it’ll take a while
05:59 #dri-devel: < EdB> Horrorcat: some will failed and some will crash
06:00 #dri-devel: < EdB> Horrorcat: ./piglit summary html ./summary/cl_test ./results/cl_test fo an html summary
06:00 #dri-devel: < Horrorcat> ah cool
06:08 #dri-devel: < Horrorcat> EdB:
06:10 #dri-devel: < Horrorcat> is that helpful or is there anything else I should get you?
06:13 #dri-devel: < EdB> Horrorcat: we could enable OpenCL1.2, please wait a minute
06:13 #dri-devel: < Horrorcat> okay
06:13 #dri-devel: < Horrorcat> will be away for today though
06:13 #dri-devel: < Horrorcat> query me the instructions
06:13 #dri-devel: < Horrorcat> will do it tomorrow then
06:13 #dri-devel: < Horrorcat> gotta go
06:15 #dri-devel: < EdB> Horrorcat: apply on mesa, then rebuild
06:16 #dri-devel: < EdB> Horrorcat: and then ./piglit run cl ./results/cl_test_1.2 and then ./piglit summary html ./summary/cl_compare ./results/cl_test ./results/cl_test_1.2 for an html summary
06:21 #dri-devel: < EdB> Horrorcat: are you working on fluid sim ?
06:28 #dri-devel: < arnop> Hello, i would like to continue discussion initiated by benjiG, yesterday. That concerns [PATCH RFC V2 0/5] another generic audio hdmi codec proposal ( I'm the author...)
06:28 #dri-devel: < arnop> Could it possible that someone from DRM community gives his opinion as the subject concerns ALSA but also DRM?
06:28 #dri-devel: < arnop> Or Russel King's comments are sufficient?
06:33 #dri-devel: < EdB> Horrorcat: are you sure you use the freshly build mesa ?
06:35 #dri-devel: < EdB> it's strange that clinfo report no plateform
06:52 #dri-devel: < pmoreau> EdB: glxinfo is reporting "10.6.3 (git-ccef890)" in his summary
06:52 #dri-devel: < pmoreau> So, not the latest one :-)
06:53 #dri-devel: < xexaxo> aboll_: gar... I've picked it up for 10.6 but forgot 11.0. will do - thanks for the reminder :)
06:55 #dri-devel: < linkmauve1> Where could I find an example userspace application using nuclear pageflip?
06:55 #dri-devel: < EdB> pmoreau: got cath :o)
06:55 #dri-devel: < aboll_> xexaxo: np
06:55 #dri-devel: < linkmauve1> Mostly how to use both an overlay plane and a primary one together.
06:56 #dri-devel: < EdB> pmoreau: how is going your effort on opencl on nvidia?
06:56 #dri-devel: < pmoreau> EdB: Slowly: I haven't had much time to work on it during the last two weeks.
06:58 #dri-devel: < pmoreau> I finished passing the SPIR-V binary from clover to Nouveau, and enough of the plumbing is done so that the hello_world from tstellar *runs*.
06:59 #dri-devel: < pmoreau> And by run, I mean it didn't crash
06:59 #dri-devel: < tstellar> pmoreau: Where did you get the SPIR-V binary from?
06:59 #dri-devel: < EdB> pmoreau, tstellar I was wondering the same :P
06:59 #dri-devel: < pmoreau> For now, it was just a GLSL fragment shader compiled to SPIR-V using glslang :-)
07:00 #dri-devel: < pmoreau> Just to test the plumbing between clover and Nouveau
07:00 #dri-devel: < EdB> ok
07:00 #dri-devel: < EdB> pmoreau: any difficulty with clover?
07:01 #dri-devel: < pmoreau> I'll have to generate the binary by hand for OpenCL kernels I guess... Or do some more searching on the internet for some compilers
07:02 #dri-devel: < pmoreau> EdB: Not really so far, but I basically just added a fake handling of SPIRV-IR inside clover.
07:03 #dri-devel: < pmoreau> So, hard coding the kernel's name and argument, and kernel data as the content of a binary file.
07:05 #dri-devel: < EdB> pmoreau: we will need to handle spir-v porperly in clover, but I'm waiting for the llvm effort to mature before that
07:05 #dri-devel: < pmoreau> Any news about the LLVM <-> SPIR-V backend? The latest I found was on the LLVM ML in July with some redesign on the todo list.
07:05 #dri-devel: < pmoreau> yeah :-)
07:07 #dri-devel: < pmoreau> EdB: Is there a repo somewhere containing a WIP implementation of SPIR-V in LLVM?
07:08 #dri-devel: < EdB> pmoreau: I don't know any one, but I'm not following it very closely
07:09 #dri-devel: < EdB> pmoreau: I'm short of time just like you
07:09 #dri-devel: < EdB> :o)
07:09 #dri-devel: < pmoreau> :|
07:10 #dri-devel: < pmoreau> Hopefully in a few weeks, most of the time eating stuff should have been taken care of.
07:10 #dri-devel: < pmoreau> tstellar: Maybe you have some inputs on a repo with SPIR-V <-> LLVM WIP?
07:12 #dri-devel: < pmoreau> At least we should hear some more about it when the final SPIR-V 1.0 draft is released.
07:12 #dri-devel: < EdB> pmoreau: anyway, I may not be able to help you, since I don't owe a nv card, but if I can help you with get it work whit clover, don't hesitate to ask
07:13 #dri-devel: < xexaxo> imirkin: not too sure what you mean with "the issue is real both ways", but I'll pull out the commit
07:13 #dri-devel: < EdB> s/owe/have
07:13 #dri-devel: < pmoreau> EdB: Ok, thanks! :-)
07:13 #dri-devel: < tstellar> pmoreau: I'm not sure what the current status of that is. My recomendation is to write a simple LLVM IR -> nv translator once you want to start compiling OpenCL C kernel.s
07:14 #dri-devel: < jekstrand> robclark: Are you using variablees in ir3 or tgsi_to_nir? If so, I just sent some nifty helpers for you.
07:14 #dri-devel: < tstellar> pmoreau: It shouldn't be too much work to get something basic up and running.
07:15 #dri-devel: < robclark> yeah, we use variables for arrays..
07:15 #dri-devel: < pmoreau> tstellar: More likely LLVM IR -> SPIR-V that directly going to NV50 IR, or? As the SPIR-V -> NV50 IR is still going to be necessary
07:15 #dri-devel: < pmoreau> s/that/than
07:16 #dri-devel: < robclark> jekstrand, yeah, I guess ttn could probably use those helpers.. I guess it's case is a bit simpler since we only create global variables (we don't really have subroutines yet)
07:18 #dri-devel: < jekstrand> robclark: Yeah. Creating variables has always been too painful. I've been doing some experiments with writing shaders directly in NIR and these helped a lot.
07:19 #dri-devel: < xexaxo> hmm seems like I forgot to Cc radeon people for the 11.0 trivial conflicts :\
07:19 #dri-devel: < xexaxo>
07:19 #dri-devel: < xexaxo>
07:19 #dri-devel: < robclark> oh, you mean programatically? (or did you make a nir assembler :-P)
07:19 #dri-devel: < jekstrand> programatically
07:19 #dri-devel: < xexaxo> mareko, MrCooper: do you guys have a couple of minutes to check if ^^ are correct.
07:19 #dri-devel: < tstellar> pmoreau: If you get to the point where you want to compile OpenCL C kernels, my recommendation is not to wait around for LLVM IR -> SPIR-V. A simple LLVM IR -> NV50 IR translator sholdn't be too hard.
07:20 #dri-devel: < tstellar> pmoreau: By simple translator I mean one that supports a subset of OpenCL features, like maybe load/store and scalar types only.
07:21 #dri-devel: < pmoreau> tstellar: Right, but I was saying that, as I'll have to do a SPIR-V -> NV50 IR translator anyhow, maybe I should write a LLVM IR -> SPIR-V rather than LLVM IR -> NV50 IR directly. Or is the latter way easier than the former?
07:23 #dri-devel: < pmoreau> (And I already have some really basic SPIR-V to NV50 IR translator)
08:01 #dri-devel: < tstellar> pmoreau: I think a LLVM IR -> SPIR-V translator will appear at some point.
08:08 #dri-devel: < mareko> xexaxo: they look ok
08:51 #dri-devel: < jekstrand> nroberts: Did you mention something at one point about being able to shorten mlen on textures if we don't use all of the components?
08:52 #dri-devel: < jekstrand> nroberts: If so, on what hardware?
08:53 #dri-devel: < nroberts> jekstrand, yes, if the trailing arguments are zero then you don't need to send them. I think this is on all hardware except for the ones where there is no opcode and the mlen determines the message type
08:53 #dri-devel: < nroberts> jekstrand, i've already landed the patch for this
08:54 #dri-devel: < nroberts> jekstrand, see fs_visitor::opt_zero_samples
09:06 #dri-devel: < jekstrand> nroberts: What about rlen?
09:06 #dri-devel: < nroberts> jekstrand, I don't know, I don't remember seeing anything about that in the spec
09:06 #dri-devel: < jekstrand> ok
09:24 #dri-devel: < gabbayo> agd5f: Hi. Did you see my email about hsakmt ?
09:25 #dri-devel: < tstellar> gabbayo: I saw it and I'm glad someone is cleaning that up.
09:25 #dri-devel: < gabbayo> I'm waiting to hear some feedback from JB or agd5f, but nothing as of yet
09:40 #dri-devel: < agd5f> gabbayo, yeah, I saw it, but I haven't had a chance to read it in detail yet
09:45 #dri-devel: < agd5f> gabbayo, looks good to me. I guess John would have the final say
09:45 #dri-devel: < jekstrand> janesma: Unfortunately, that GPU hang seems reproducable by kicking off a jenkins job but I can't reproduce it on my HSW desktop
09:46 #dri-devel: < gabbayo> yes, could you please ping him sometime next week ? I can't reach him for some reason
09:46 #dri-devel: < agd5f> gabbayo, will do
09:46 #dri-devel: < gabbayo> agd5f: thx!
09:47 #dri-devel: < janesma> jekstrand: I'll take a look at it.
10:20 #dri-devel: < DottorLeo> hi!
10:21 #dri-devel: < DottorLeo> EdB, is clover now OpenCL 1.2 compliant?
10:21 #dri-devel: < DottorLeo> < EdB> Horrorcat: we could enable OpenCL1.2, please wait a minute
10:26 #dri-devel: < jekstrand> Kayden: To you knowlege have write masks ever been allowed in SIMD8/16 texturing instructions?
10:27 #dri-devel: < jekstrand> Kayden: Using them seems to make my gpu very angry :-/
10:34 #dri-devel: < EdB> DottorLeo: no really, it's a patch to pretend it
10:34 #dri-devel: < DottorLeo> just for curiosity, have you tried with blender cycles OpenCL kernel lately?
10:35 #dri-devel: < EdB> DottorLeo: we are heading to it, but not yeah ready
10:35 #dri-devel: < DottorLeo> nice to hear :)
10:35 #dri-devel: < EdB> DottorLeo: I've try it a mouth ago
10:35 #dri-devel: < Kayden> jekstrand: They don't work remotely like you think
10:35 #dri-devel: < Kayden> jekstrand: See anholt/i965-texture-writemask from several years ago
10:35 #dri-devel: < EdB> DottorLeo: do you need cl 1.2 for an app?
10:35 #dri-devel: < DottorLeo> do you know what is missing?
10:36 #dri-devel: < DottorLeo> i'm not sure...i can't tell if blender uses opencl 1.1 or opencl 1.2
10:36 #dri-devel: < DottorLeo> :/
10:36 #dri-devel: < Kayden> jekstrand: There was also a recent discussion about this on intel mailing lists - see Petri's most recent MSR, where I asked if anybody had any actual data about whether this saves memory bandwidth / cache storage or if it just cuts register usage
10:37 #dri-devel: < EdB> DottorLeo: some host fonction (there are stubed for the moment, you can grep for them in clover) and also runtime part is not complet
10:37 #dri-devel: < Kayden> jekstrand: and then had Kevin explain to me, without any actual data, that it obviously does so and I must not know what I'm talking about.
10:38 #dri-devel: < DottorLeo> what about image support, was merged from zogi patch?
10:38 #dri-devel: < Kayden> even though for, say, 8-bit RGBA, a pixel is a single 32-bit value, and I *really* don't think that they're working in smaller than cacheline sized chunks
10:38 #dri-devel: < Kayden> because that would be crazy
10:38 #dri-devel: < EdB> DottorLeo: I think I will give blender cycle another try but I don't have the time for the moment
10:39 #dri-devel: < DottorLeo> no problem, if someone need OpenCL support for radeon badly i think it will use the fglrx
10:39 #dri-devel: < EdB> DottorLeo: some zogi patches are merged
10:42 #dri-devel: < DottorLeo> good!
10:45 #dri-devel: < mattst88> jekstrand: basically, the writemask is part of the message header, not the writemask bits in the instruction word
10:45 #dri-devel: < mattst88> jekstrand: and in SIMD8, it just doesn't write some parts of the returned data
10:46 #dri-devel: < mattst88> jekstrand: whereas in SIMD16 it actually skips pairs of registers, such that a writemask of .xw would write xxww into 4 registers, skipping y and z
10:46 #dri-devel: < mattst88> jekstrand: but the problem is that in order to use writemasking, you have to *add* a header in almost all cases
10:48 #dri-devel: < Kayden> which eliminates most of the register usage benefits you might've gained
10:48 #dri-devel: < Kayden> and actually increases instruction count
10:49 #dri-devel: < Kayden> so it'd probably be worth doing if it actually saved bandwidth or cache, but I have no evidence that it does
11:07 #dri-devel: < jekstrand> mattst88, Kayden: Yes, I'm aware that you have to add a header and that's where the writemask bits go. However, I can't get it to not hang my GPU.
11:08 #dri-devel: < Kayden> You found documentation saying it doesn't exist on BDW+?
11:09 #dri-devel: < jekstrand> In the docs for the message header: "Alpha/Blue/Green/Red channels masked must set to 0 (no mask is supported)."
11:09 #dri-devel: < jekstrand> and setting a mask hangs the GPU
11:09 #dri-devel: < jekstrand> Also the bspec has the line "write masks are not supported on SNB"
11:09 #dri-devel: < jekstrand> It also hangs HSW
11:10 #dri-devel: < mattst88> weird.
11:10 #dri-devel: < imirkin> i guess they can't just throw in an assert, huh
11:11 #dri-devel: < jekstrand> Maybe I got the mlen wrong...
11:11 #dri-devel: < jekstrand> rlen rather
11:12 #dri-devel: < Kayden> Weird, it looks like that only applies to SNB
11:13 #dri-devel: < jekstrand> Yup, that was it. I just had the writemask all wrong.
11:13 #dri-devel: < mattst88> looking at the BDW PRM, the "Alpha/Blue/Green/Red channels masked must set to 0" text seems suspicious
11:14 #dri-devel: < jekstrand> yeah, it totally works if you don't screw up rlen.
11:14 #dri-devel: < jekstrand> Hopefully I'll have a benchmarkable patch soon.
11:17 #dri-devel: < mattst88> jekstrand: are you implementing what Petri has been working on for the last month?
11:17 #dri-devel: < Kayden> yes
11:17 #dri-devel: < Kayden> and anholt already did years ago
11:18 #dri-devel: < Kayden> (worth trying again, and it'll be nice to see some new data on it...)
11:18 #dri-devel: < jekstrand> mattst88: I guess
11:19 #dri-devel: < mattst88> jekstrand: what prompted this?
11:19 #dri-devel: < jekstrand> I didn't know anyone was working on it
11:19 #dri-devel: < jekstrand> Harri's MSR and the "This would be super-easy with NIR" thought.
11:20 #dri-devel: < mattst88> ah, okay
11:20 #dri-devel: < mattst88> yeah, Petri's last two MSRs have talked about him working on this
11:20 #dri-devel: < Kayden> two?
11:21 #dri-devel: < jekstrand> I figure I can hack something out in a couple of hours and we can benchmark it instead of going back and forth on MSR's about whether or not it's a good idea.
11:21 #dri-devel: < mattst88> yeah, first one mentioning it was Sept 3rd
11:21 #dri-devel: < mattst88> he was apparently sick for two weeks this month
11:21 #dri-devel: < mattst88> I'd hate to preempt him on something he's been working on for 6 weeks, but then again he never even finished the minmax optimization
11:22 #dri-devel: < mattst88> Kayden: the Sept 3rd MSR was the one that spawned the thread with Kevin
11:27 #dri-devel: < mattst88> of course, his code is no where to be found either, even though his MSR from yesterday says he has everything working pending some kerbal space program spilling
11:45 #dri-devel: < jekstrand> bah, swizzling...
11:53 #dri-devel: < janesma> jekstrand: I couldn't repro the hang running serially.
11:54 #dri-devel: < janesma> but I have a set of tests that could be causing it.
11:55 #dri-devel: < jekstrand> ok...
11:55 #dri-devel: < janesma> also, if you want the error state.
11:56 #dri-devel: < jekstrand> janesma: Is it reliable enough that we can at least attempt a bisect?
11:57 #dri-devel: < janesma> well, it seems like it reproduces reliably when running concurrently.
11:57 #dri-devel: < janesma> what would be most helpful to you?
11:58 #dri-devel: < jekstrand> If you've got some subset of tests that you think reproduces it, then I can try and bisect.
11:58 #dri-devel: < jekstrand> This whole thing seems really fishy
11:58 #dri-devel: < jekstrand> I'm kind of surprised it's hanging the GPU
11:58 #dri-devel: < jekstrand> There's one patch in there that's kinda sketchy but getting hangs wasn't expected at all
11:58 #dri-devel: < janesma> I have a set of tests that were running when the hang occured.
11:59 #dri-devel: < janesma> I'll see if the hang happens with just those tests running.
11:59 #dri-devel: < jekstrand> ok
12:09 #dri-devel: < jekstrand> well, here goes piglit...
12:10 #dri-devel: < janesma> jekstrand: smaller test set doesn't reproduce the hang.
12:10 #dri-devel: < jekstrand> *sigh
12:10 #dri-devel: < jekstrand> and we aren't getting any hangs on master?
12:10 #dri-devel: < janesma> max-varyings is always in the fail set. I should be able to bisect on that.
12:10 #dri-devel: < janesma> no.
12:11 #dri-devel: < jekstrand> probably not
12:11 #dri-devel: < jekstrand> max_varyings just takes a really long time. That's why it's always running durring the hang
12:11 #dri-devel: < janesma> right.
12:12 #dri-devel: < janesma> my automation is set up to bisect piglit failures, not gpu hangs.
12:12 #dri-devel: < janesma> It would be really nice if we could figure out what process triggered the hang, and print the command line for it.
12:13 #dri-devel: < janesma> in dmesg.
12:13 #dri-devel: < Kayden> we do, but it's always "shader_runner"
12:13 #dri-devel: < Kayden> you really want the arguments as well
12:13 #dri-devel: < janesma> right.
12:14 #dri-devel: < jekstrand> that silly shader_runner test... why is it always hanging?...
12:16 #dri-devel: < imirkin_> can anyone explain the difference between "coherent" and "volatile" for image/ssbo? i'm looking at the image spec, where it explains clearly what they mean, but i'm having trouble finding the difference between the two definitions
12:17 #dri-devel: < imirkin_> is coherent basically volatile + restrict?
12:18 #dri-devel: < mareko> imirkin_: would you give me Rb please?
12:19 #dri-devel: < imirkin_> mareko: i'm not really familiar with scan shader. i don't think nouveau really uses it... anyways, your code seems reasonable, but i'd really prefer a { } there
12:19 #dri-devel: * vsyrjala looks at procfs cmdline code
12:20 #dri-devel: < vsyrjala> ~200 loc of fragile looking code just to get it
12:20 #dri-devel: < vsyrjala> wouldn't want to replicate that in the driver
12:30 #dri-devel: < gabbayo> imirkin_: hi
12:30 #dri-devel: < gabbayo> imirkin_: just wanted to update you regarding the varying simple double test you helped me with
12:32 #dri-devel: < gabbayo> imirkin_: apparently, the problem lies in an llvm module called: "aggressive anti dependency breaker", in an obscure function that I have no idea what it does. I only know that if I change some function call there, suddenly the test works (the generated shader assembly changes quite a bit)
12:33 #dri-devel: < gabbayo> of course, I didn't reach it by my own. someone tried to simplify that function, and by mistake he changed it so its working now. Unfortunately, they are now going to revert it because that change is wrong (even though it solved my problem)
12:33 #dri-devel: < gabbayo> I think that even if I had worked on that bug for another 2 months I wouldn't arrive to that function :(
12:33 #dri-devel: < imirkin_> gabbayo: good to know. makes sense that the error was in llvm
12:33 #dri-devel: < imirkin_> gabbayo: can you disable that pass somehow?
12:34 #dri-devel: < gabbayo> well, there supposed to be a flag that controls if you want to use that module or not
12:34 #dri-devel: < gabbayo> mesa doesn't set that flag at all, so it should be set to "none". But because we do pass through that module, someone in llvm is overriding it
12:34 #dri-devel: < imirkin_> ah, you should have mesa disable it on ppc then
12:35 #dri-devel: < gabbayo> or I should fix llvm :)
12:35 #dri-devel: < gabbayo> in about 2-3 months after I learned that as well ;)
12:36 #dri-devel: < imirkin_> gabbayo: see gallivm_compile_module -- it has all kinds of workarounds
12:36 #dri-devel: < gabbayo> It actually fixes some more piglit tests on ppc64le. I got down to only 8 differences between x86-64 and ppc64le with this "fix"
12:36 #dri-devel: < gabbayo> ok
12:36 #dri-devel: < gabbayo> will look
12:36 #dri-devel: < imirkin_> or maybe functionattr is the wrong thing
12:36 #dri-devel: < imirkin_> but... you get the general idea :)
13:08 #dri-devel: < janesma> jekstrand: first hang I got was with i965/vs: Move use_legacy_snorm_formula into the shader key
13:31 #dri-devel: < jekstrand> janesma: Yeah, that's what I figured...
13:32 #dri-devel: < jekstrand> I can work that patch out of the series.
13:32 #dri-devel: < jekstrand> I would like to know why it breaks things though.
13:32 #dri-devel: < jekstrand> Kayden: Any ideas?
13:34 #dri-devel: < janesma> jekstrand: I think you bug is here:
13:34 #dri-devel: < janesma> if ((wa_flags & BRW_ATTRIB_WA_SIGN) &&
13:34 #dri-devel: < janesma> !key->use_legacy_snorm_formula) {
13:34 #dri-devel: < janesma>
13:35 #dri-devel: < janesma> elsewhere use_legacy_snorm_formula = !_mesa_is_gles3(&brw->ctx)
13:35 #dri-devel: <+anholt> danvet: my crtc_mode_set_nofb's crtc->state->state is NULL. Where should I be getting the atomic_state for this modeset at that point?
13:35 #dri-devel: < mattst88> janesma: my last two jenkins runs have failed to build. first was drm. second was deqp and piglit. I don't suspect either are my doing.
13:35 #dri-devel: <+anholt> (I need to figure out which encoder is attached)
13:36 #dri-devel: < janesma> mattst88: sorry, I was updating builder-01 and it caused errors for builds.
13:36 #dri-devel: < mattst88> ahh
13:36 #dri-devel: < janesma> I built too many parallel builds for jekstrand, and they spilled over onto that machine.
13:36 #dri-devel: < janesma> I just started your buildagain.
13:37 #dri-devel: < mattst88> thanks
13:39 #dri-devel: < jekstrand> janesma: hrm... I don't think so. That hunk just adds a key->
13:40 #dri-devel: <+anholt> danvet: I guess I should be just walking the global connector list.
13:42 #dri-devel: < janesma> jekstrand: yeah, you are right.
13:43 #dri-devel: < jekstrand> janesma: How's jenkins' hang recovery doing these days? I have some patches that *should* work on *some* hardware but I have no idea what hardware.
13:43 #dri-devel: < janesma> it should be fine for everything other than hard-hang.
13:44 #dri-devel: < jekstrand> ok
13:44 #dri-devel: < janesma> If you think you might hard-hang systems, make sure Dylan is around to reboot the machines.
13:44 #dri-devel: < jekstrand> Will it quite part-way through if it starts hanging?
13:44 #dri-devel: < jekstrand> *quit
13:44 #dri-devel: < jekstrand> or at the very least time out after 20 minutes or something like that
13:44 #dri-devel: < janesma> no, it checks for gpu hang after the run finishe
13:45 #dri-devel: < janesma> yes, there is a timeout, which can be dependent on the machine.
13:45 #dri-devel: < janesma> slow machines->longer timeout.
13:45 #dri-devel: < jekstrand> yup
13:45 #dri-devel: < janesma> default timeout is 40 min.
13:47 #dri-devel: < jekstrand> ok
13:51 #dri-devel: < jekstrand> alright, I just kicked off a job but i made my changes BDW-only so it shouldn't take down jenkins.
13:51 #dri-devel: < jekstrand> I know for sure that HSW doesn't like them.
14:10 #dri-devel: < Kayden> jekstrand: what did you want me to look at?
14:17 #dri-devel: < janesma> Kayden: in jekstrand's repo, "53c50a8 : Move use_legacy_snorm_formula into the shader key" causes gpu hang on hsw.
14:19 #dri-devel: < Kayden> what?
14:19 #dri-devel: < Kayden> haswell doesn't even use this code
14:20 #dri-devel: < Kayden> wa_flags should be 0
14:20 #dri-devel: < Kayden> all the time
14:20 #dri-devel: < Kayden> jekstrand: (while I'm looking at this) you should set that in the precompile function too
15:02 #dri-devel: < danvet> anholt, yeah once committed the backpointers are null
15:02 #dri-devel: < danvet> since they'll outlive the drm_atomic_state
15:02 #dri-devel: < danvet> anholt, what do you need to walk connectors for?
15:31 #dri-devel: < imirkin_> there's no way to use glVertexAttribPointer with ARB_vertex_program shaders right?
15:33 #dri-devel: < jekstrand> Kayden: Yes, we should. We migh also want to predicate it on gen < something
15:34 #dri-devel: < jekstrand> I do know that it's causing recompiles
15:34 #dri-devel: < jekstrand> Interestingly enough, I can't reproduce on my HSW desktop even with a full piglit run
15:34 #dri-devel: < jekstrand> janesma: ^^
15:34 #dri-devel: < jekstrand> Maybe there's some 64 vs. 32-bit thing going on?
15:35 #dri-devel: < janesma> jekstrand: I built m64 on the CI to eliminate that possibility
15:35 #dri-devel: < janesma> what kernel do you have?
15:36 #dri-devel: < janesma> I updated the hsw systems to 4.2. I also reproduced on hswgt3e, but maybe I should try another sku.
15:36 #dri-devel: < Kayden> jekstrand: I don't see why
15:36 #dri-devel: < jekstrand> janesma: 3.17.6-300.fc21.x86_64
15:36 #dri-devel: < jekstrand> Kayden: why it causes recompiles?
15:37 #dri-devel: < jekstrand> Kayden: Meta can change whether or not you're gles
15:37 #dri-devel: < Kayden> jekstrand: no, I don't see why we would add a gen check. it just means splattering gen checks in more places. the code that does workarounds is cued off of a flag that says you need them...
15:37 #dri-devel: < Kayden> and the flag is always 0 on haswell+
15:37 #dri-devel: < Kayden> oh, gah
15:37 #dri-devel: < Kayden> that's an unforeseen consequence...we don't want to change that
15:41 #dri-devel: < janesma> Kayden, jekstrand: I also am not understanding why the hangs don't repro when running tests serially.
15:41 #dri-devel: < Kayden> that doesn't make sense either..
15:41 #dri-devel: < jekstrand> Really, the driver should be fairly robust against that, but it looks like it happens in the test cases I've looked at that are around hangs.
15:43 #dri-devel: < janesma> well, I just failed to repro on hswgt2. So either it is intermittent and fooling me, or reproduces better on hswgt3e
15:44 #dri-devel: < jekstrand> That could explain why I'm not seeing it on ny desktop. It's a gt3 but not e
16:05 #dri-devel: * jekstrand is beginning to think that write masking textures might be better done as an optimization pass...
16:06 #dri-devel: < Kayden> at this point, I think you've exceeded your hour or two of coding and it might be better to just ask Adrinael for a copy of his code that's already debugged
16:07 #dri-devel: < jekstrand> yeah
16:07 #dri-devel: < jekstrand> I think i'm gonna call it a day on this one
16:07 #dri-devel: < jekstrand> Although now that I've got the separate pass idea, I'm getting tempted to start on that...
16:07 #dri-devel: < jekstrand> Probably no point if he's already got it working though
16:07 #dri-devel: < Kayden> remember the point is to see if it's worth doing
16:08 #dri-devel: < jekstrand> I know
16:08 #dri-devel: < jekstrand> But it's friday...
16:09 #dri-devel: < Kayden> it's already Saturday for some people here :)
16:10 #dri-devel: < jekstrand> ...
16:18 #dri-devel: < linkmauve1> Any reason GL_KHR_debug is a permanently-enabled extension, and impossible to disable using MESA_EXTENSION_OVERRIDE?
16:18 #dri-devel: < linkmauve1> Or just nobody wired it that way yet?
16:20 #dri-devel: < Kayden> why would you?
16:20 #dri-devel: < Kayden> there are a lot of extensions like that
16:20 #dri-devel: < linkmauve1> I wanted to test if my application ran fine on drivers that don’t have this extension.
16:39 #dri-devel: < imirkin_> linkmauve1: the MESA_EXTENSION_OVERRIDE thing is a little dodgy -- it doesn't actually control which exts are exposed, but rather which enable flags are set.
16:39 #dri-devel: < imirkin_> linkmauve1: and there is no enable flag for KHR_debug
16:39 #dri-devel: < imirkin_> so no way to turn it off
16:40 #dri-devel: < janesma> Kayden, jekstrand: hswgt2 reproduces the gpu hang fairly reliably also, beginning with the same commit "Move use_legacy_snorm_formula into the shader key"
16:40 #dri-devel: < linkmauve1> Ok.
16:40 #dri-devel: < janesma> There was one test run in my sequence that did not generate the hang.
16:41 #dri-devel: < Kayden> linkmauve1: Oh, that makes sense...I hadn't considered that. Not sure there's a good solution, though :(
16:42 #dri-devel: < janesma> The other 15 or so reliably passed/failed. There was a bit of confusion because two of jekstrand's build timed out after hanging, and those hangs were wrongly attributed.
16:42 #dri-devel: < linkmauve1> Pull request sent anyway, I’ll wait for someone to tell me if that made something break. ^^
16:51 #dri-devel: < jekstrand> janesma: Other 15 what?
16:51 #dri-devel: < jekstrand> platforms?
16:51 #dri-devel: < janesma> I built every rev in your series.
16:52 #dri-devel: < janesma>
17:15 #dri-devel: < nchery> imirkin_: afaik, MESA_EXTENSION_OVERRIDE does affect which extensions are advertised.
17:15 #dri-devel: < imirkin_> nchery: not directly
17:15 #dri-devel: < imirkin_> nchery: only indirectly, by affecting the enable flags
17:18 #dri-devel: < nchery> imirkin_: yes, I agree that it does modify the strings indirectly. It modifies the driver capability booleans in the context's gl_extensions struct. I'm not sure what you mean by enable flags..
17:19 #dri-devel: < mattst88> for extensions that are always enabled (i.e., don't have enable flags of their own and use dummy_true), MESA_EXTENSION_OVERRIDE will not work
17:19 #dri-devel: < mattst88> instead you hit a _mesa_problem and an unreachable() IIRC
17:29 #dri-devel: < nchery> linkmauve1: If you don't mind compiling mesa, I have a branch which should enable you to turn of KHR_debug.
17:31 #dri-devel: < linkmauve1> nchery, I already compile it every time. :)
17:31 #dri-devel: < linkmauve1> Is it a hack or something that could be integrated upstream?
17:33 #dri-devel: < nchery> linkmauve1: great :) It's a work in progress. I'm planning to send out the patches to a variation of it to the mailing list soon. Those patches won't have the disabling feature because of the amount of code that's modified needed to get it working.
17:34 #dri-devel: < linkmauve1> Great, thank you!
17:34 #dri-devel: < nchery> no problem!
17:56 #dri-devel: < linkmauve1> nchery, I just tested it, works fine, thanks. :)
21:41 #dri-devel: <+anholt> down to 82 patches on top of the kms series to get v3d support. what a mess.
21:41 #dri-devel: < Kayden> v3d?
21:41 #dri-devel: <+anholt> the rendering engine
21:41 #dri-devel: < Kayden> eesh :(
21:44 #dri-devel: < imirkin> anholt: but at least no more dt fights?
21:48 #dri-devel: <+anholt> ha ha ha
21:49 #dri-devel: < imirkin> tbh i don't understand how you guys put up with the abuse
21:50 #dri-devel: < imirkin> just stick it all in the cmdline and move on
21:56 #dri-devel: <+anholt> most of the DT bikeshedding feels the same as the rest of the kernel bikeshedding. unless the higher-ups start telling people to not be dicks, I don't see any solution.
21:57 #dri-devel: < imirkin> the stakes are a lot lower and it's a lot easier to change stuff around, which i find tends to lead to a lot more bikeshedding
21:58 #dri-devel: < imirkin> but you're probably right -- personality plays into it too
22:00 #dri-devel: < imirkin> imo people are too eager to accept unnecessary feedback. i try to avoid giving it, as well as accepting it. probably works differently when you have an actual job to do and that job is to get a piece of code upstream.
22:02 #dri-devel: <+anholt> one way of looking at the problem: maintainers feel like they need to get impeccable code in, or their parent might NAK their pulls. so, unless the parent threatens to also NAK them unless they don't be dicks to their contributors about the code being impeccable, the incentives push toward where we are today.
22:03 #dri-devel: < imirkin> heh
22:03 #dri-devel: < imirkin> nak for too-perfect-code -- probably not going to happen
22:04 #dri-devel: <+anholt> not for that, for "you are being too nitpicky during review and driving away contributors, stop that or I will stop pulling from you."

Written by Christoph Brill © 2007-2015

Valid XHTML 1.0 Transitional

Available in Android Market