00:18 glisse: skeggsb: what is the super bool for in nvif_client ?
00:19 skeggsb: glisse: it lets the client do stuff you don't want userspace to be able to do
00:20 skeggsb: like, make dma objects that cover random areas of memory
00:31 glisse: hhmmm, so i can't use the drm file client to create pfault object
00:31 skeggsb: from kernel code?
00:32 skeggsb: sure you can, set it temporarily, and revert back to false afterwards
00:32 glisse: :)
00:32 skeggsb: we do that already in a few places, mostly pre-g80, but yeah
00:33 skeggsb: just make sure you hold the client mutex while you do it, or userspace will be able to sneak something bad in
00:34 karolherbst: only 60 failing tests to go now for 4.4 :)
00:38 glisse: skeggsb: btw do you know what the mx150 is ? a gp108 ?
00:38 glisse: mx150 being newest laptop pascal gpu for small laptop
00:39 skeggsb: nfi
00:41 imirkin: glisse: https://pci-ids.ucw.cz/read/PC/10de/1d10
00:41 glisse: lovely
01:50 whompy: karolherbst: I was catching up on backlog and preparing to ask you about cts status. beat me to it.:)
01:51 whompy: any groups or just individual tests here and there?
08:28 karolherbst: whompy: both
11:51 rhyskidd_: glisse: Yes, the MX150 is a GP108
16:56 karolherbst: now magically those "KHR-GL44.blend_equation_advanced.blend_specific." tests are passing, odd, super odd
16:57 karolherbst: 39 fails now...
16:57 imirkin_: take it while you can.
16:57 karolherbst: but now I am on lowest clock levels...
16:58 karolherbst: now they fail...
16:58 karolherbst: the heck
17:03 karolherbst: I reboot and see if that changes anything
17:10 pmoreau: glisse: I can't help but love the name for the HMM project! :-) We should rename nouveau to nouvelle, and then we can have paths like `drivers/gpu/drm/nouvelle/compote/de/pommes.c` :-D
17:12 karolherbst: pmoreau: :D
17:16 Bl4ckb0ne: where can we give our positive vote for this
17:20 karolherbst: Bl4ckb0ne: patch on mailing list
17:20 Bl4ckb0ne: I really need to get into those mailing list
17:24 karolherbst: I like: <Section Name="Invalid result" Description="">
17:28 glisse: pmoreau yeah all the nvidia folks thought i made a typo i had to explain why french folks like this kind of name :)
17:29 imirkin_: glisse: big fan of the name too
17:38 RSpliet: "van met die vruchten en suiker doen op water in een potje met een weck... weckdingsel erop"
17:38 RSpliet: yes, I appreciate the name too
17:41 karolherbst: <Text>Result (dvec4) [26.1916, 25.7562, 25.3208, 24.8854]</Text> vs <Text>Expected result (dvec4) [26.192, 25.7566, 25.3211, 24.8857]</Text>
17:41 karolherbst: please... this is close enough :(
17:43 imirkin_: karolherbst: srgb thing?
17:44 imirkin_: usually it's an indication that things will diverge more elsewhere
17:44 karolherbst: imirkin_: f64
17:45 karolherbst: KHR-GL44.gpu_shader_fp64.built_in_functions
17:46 imirkin_: for which function?
17:46 imirkin_: we have a LOT of inaccuracy in fp64
17:46 imirkin_: oh wait
17:46 imirkin_: dboyan fixed all that!
17:46 imirkin_: i just haven't reviewed
17:46 imirkin_: gr. totally forgot.
17:46 karolherbst: ohh nice
17:46 karolherbst: where is the series?
17:46 imirkin_: apply his patches.
17:47 imirkin_: https://github.com/dboyan/mesa/commits/fp64-rcprsq2
17:47 karolherbst: thx
17:47 imirkin_: not *100%* sure that this is the latest
17:47 imirkin_: unfortunately he's only done it for GK110
17:48 karolherbst: ohh, k
17:48 imirkin_: should be relatively easy to adapt to nvc0
17:48 imirkin_: just literally copy everything and then make minor adjustments until envyas is happy
17:48 karolherbst: yeah, k
17:48 imirkin_: he did a really good job with those.
17:49 imirkin_: too bad he didn't have the time for the GSoC =/
17:49 karolherbst: what happened by the way? I didn't really follow it
17:49 imirkin_: but yeah, our RCP/RSQ was horrid. our SQRT should also get a separate impl, since 1/RSQ doesn't cut it.
17:49 imirkin_: he overcommitted his time
17:49 karolherbst: k
17:51 karolherbst: it
17:51 karolherbst: 's just for rcp and rsq, right?
17:51 imirkin_: yes.
17:51 imirkin_: but other stuff relies on e.g. rcp, like division :)
17:52 karolherbst: okay
17:53 imirkin_: i really wanted to get the stuff right and properly documented on *one* arch, before copying to the others
17:55 karolherbst: mhhh, envyas complains about "cvt f64 $r6d f64 neg $r6d"
17:55 imirkin_: ok
17:55 karolherbst: "cvt f64 $r0d f32 $r0" is fine
17:56 karolherbst: okay
17:56 imirkin_: ah yeah, we fixed that for the gk110 isa
17:56 karolherbst: it's the neg
17:56 imirkin_: oh
17:56 imirkin_: is it missing?
17:56 imirkin_: or just needs to be in a diff spot?
17:56 karolherbst: I check
17:56 karolherbst: maybe my system envytools is just super old
17:56 imirkin_: well, in the gk110 isa some double things were not marked as such
17:57 karolherbst: ohh, k
17:57 karolherbst: "cvt f64 $r6d neg f64 $r6d" works
17:58 imirkin_: annoying =/
17:58 karolherbst: yeah
17:58 karolherbst: it's basically the same
17:58 karolherbst: just that one neg
17:59 karolherbst: and "set b32", the b32 needs to be removed
17:59 imirkin_: i'm happy to normalize it a bit if you like... get mwk's approval
18:00 karolherbst: rsqrt64h...
18:01 imirkin_: could be mufu
18:01 karolherbst: ohh, no f32
18:02 karolherbst: I mean, I need to remove the dType as well
18:02 karolherbst: okay, testing
18:02 imirkin_: you'll need more hookup
18:02 imirkin_: his code had restrictions about only doing it for gk110
18:03 karolherbst: yeah
18:03 karolherbst: already removed that
18:05 karolherbst: MISALIGNED_PC and ILLEGAL_INSTR_ENCODING :/
18:07 karolherbst: nice
18:08 imirkin_: fill in nop's for the scheds to work out ;)
18:08 imirkin_: oh, and you might have to stick .long's everywhere
18:09 karolherbst: ohh true
18:19 karolherbst: ILLEGAL_SPH_INSTR_COMBO
18:34 karolherbst: imirkin_: do you know what ILLEGAL_SPH_INSTR_COMBO means?
18:36 imirkin_: you forgot to set the FP64 bit
18:37 imirkin_: SPH = shader program header
18:37 imirkin_: that error means "you're using an instruction you're not supposed to without fiddling in the SPH"
18:37 karolherbst: ohh, k
18:38 imirkin_: which given the discussion topic is most likely to be fp64 stuff
18:38 imirkin_: you need to set the dtype of that OP_CALL to fp64 or something ;)
18:38 imirkin_: or teach the detector which builtins have fp64 stuff in them
18:43 karolherbst: uhm, k
18:43 karolherbst: I assume dboyan didn't solve this issue as well?
18:44 imirkin_: could be an old branch =/
18:44 imirkin_: dunno
18:44 imirkin_: or
18:44 imirkin_: could be that you lied ;)
18:45 imirkin_: hm. dunno.
18:45 imirkin_: perhaps there was other fp64 stuff in the prog
18:45 imirkin_: or perhaps the issue is entirely different
18:45 karolherbst: ohh wait
18:45 karolherbst: should be easy
18:45 imirkin_: this won't work if ALL you have is a rcp/rsq
18:45 karolherbst: there is this handleRCPRSQLib creating the CALL op
18:46 karolherbst: I could just set the fp64 flag there
18:46 imirkin_: yes.
18:47 imirkin_: Program::emitBinary in nv50_ir_target.cpp has the logic.
18:48 karolherbst: I see
18:49 imirkin_: similarly you could just set info->io.fp64 right there and then.
18:49 karolherbst: I just set the dType
18:49 karolherbst: of the call to F64
18:49 karolherbst: funny though, I get even worse results with the CTS test now
18:50 imirkin_: hehe
18:50 karolherbst: and by worse I mean totally wrong
18:50 imirkin_: check the envydis output of the envyas results
18:50 imirkin_: pastebin them, in fact
18:50 imirkin_: and your patch
18:51 karolherbst: https://gist.github.com/karolherbst/1007bef6fe2499848300a673803b0ea4
18:51 karolherbst: https://github.com/karolherbst/mesa/commit/01962f2d9568956e1890d063e323c782d31b42c8
19:02 imirkin_: karolherbst: don't see anything obviously wrong =/
19:02 imirkin_: would require investigation ... and hardware
19:02 imirkin_: [i only have gk110]
19:02 imirkin_: [at least atm]
19:04 karolherbst: okay
19:04 karolherbst: could you run the test on gk110?
19:04 karolherbst: and see how wrong the results are?
19:04 imirkin_: sure. not right now, but tonight.
19:04 karolherbst: k, thanks
19:04 imirkin_: i think that dboyan had it perfect though
19:04 imirkin_: almost bit-for-bit with nvidia
19:04 karolherbst: I see
19:04 imirkin_: or rather, almost bit-for-bit with cpu results
19:04 imirkin_: off-by-2 at most iirc
19:04 imirkin_: (2 bits of ULP that is)
19:05 imirkin_: er
19:05 imirkin_: 2 ULP's, not 2 bits.
19:05 imirkin_: might be the wrong branch, dunno
19:05 karolherbst: well the other branches look more wrong
19:06 imirkin_: which function is broken btw?
19:06 imirkin_: rcp64 or rsq64 or both?
19:07 karolherbst: I assume both
19:07 karolherbst: I could check what gets used
19:07 imirkin_: can you check with piglit tests?
19:07 imirkin_: i mean if it's totally wrong, even those will fire
19:08 imirkin_: or could be some different detail of implementation of some of those sfu ops which makes gk10x fail and gk110 succed
19:08 karolherbst: well the results differe by a lot
19:08 karolherbst: *differ
19:08 karolherbst: and by a lot I mean like instead of 0.2425 vs 0.2427 it's 5463.345 cs 0.2427 now or something like that
19:09 imirkin_: ;)
19:11 justaguy`: Can anyone point me to a list of what Nvidia cards will work with linux-libre without firmware signing? I know the 660Ti and 670 will apparently work, but I can't find a full list.
19:12 imirkin_: anything before GM20x
19:12 imirkin_: GM10x and earlier
19:12 imirkin_: (unfortunately nvidia likes to mess around with marketing names, so it can be tricky to map that to the things you buy in the store)
19:13 imirkin_: generically GTX 7xx and earlier should be fine, although i understand that nvidia released a GTX 750 v2 which is a GM20x
19:13 imirkin_: you can usually figure it out based on supported features
19:13 Bl4ckb0ne: does nouveau works with discrete graphic cards?
19:13 imirkin_: e.g. i think GM20x was the first line to support HDMI 2.0 - so if it supports that, then it won't work
19:14 imirkin_: Bl4ckb0ne: as opposed to... IGP's? if it only worked with IGP's, that'd be a pretty limited hw list...
19:14 Bl4ckb0ne: I got a gt940m on a laptop
19:14 imirkin_: could work
19:14 imirkin_: depends on specifics.
19:14 Bl4ckb0ne: NV118 apparently
19:14 Bl4ckb0ne: I´ll give it a try this week end
19:15 imirkin_: should work without trouble... i'd recommend kernel 4.10+ so that you can reclock
19:15 Bl4ckb0ne: reclock ?
19:15 imirkin_: change clocks from the lowest clocks that the gpu's boot into
19:16 imirkin_: i.e. if you want more than 0.0001fps
19:17 justaguy`: imirkin_: Thank you for the advice. Would it be safe to say that this card would work with linux-libre? http://www.ebay.ca/itm/ASUS-NVIDIA-GeForce-GTX660-DC20-2GD5-PCI-E-Graphics-Card-/172807090578?hash=item283c1af192:g:gB8AAOSwlmxZb5bv
19:18 imirkin_: no.
19:18 imirkin_: congratulations on picking the one GTX xxx gpu that *might* have issues
19:19 imirkin_: there are some reports of GTX 660's not working well
19:19 imirkin_: without using proprietary firmware
19:19 justaguy`: Dang.
19:19 imirkin_: skeggsb hasn't been able to reproduce, which is kinda required for him to be able to investigate/fix.
19:19 imirkin_: afaik that's the only GPU model of the generation that has shown issues with nouveau's firmware
19:19 imirkin_: and even then, it's not all of them
19:19 imirkin_: but some :)
19:20 justaguy`: What would you recommend if I need something to be able to drive 3 displays (but no gaming)?
19:20 imirkin_: well ... all keplers should be able to drive 3 displays
19:21 imirkin_: realistically i'd recommend an AMD gpu ;)
19:21 imirkin_: that's well-supported by the community
19:21 justaguy`: But AMD starting requiring signed microcode before Nvidia did, right? So I'd have to get an older GPU?
19:21 imirkin_: afaik AMD's microcode isn't signed
19:22 imirkin_: but it's also not community-developed
19:22 justaguy`: Ah, right. But it's still proprietary so it wouldn't work with linux-libre, right?
19:22 imirkin_: well, even if it were open it wouldn't work with linux-libre.
19:22 imirkin_: linux-libre afaik just kills request_firmware
19:28 justaguy`: What about this one? http://www.ebay.ca/itm/ZOTAC-VIDEO-CARD-GeForce-GTX-650-Synergy-Edition-/292208282280?hash=item4408f88aa8:g:wk0AAOSwOwZZift7
19:29 imirkin_: it's highly likely to work. but that's really expensive... i can probably find a much cheaper board if you want.
19:29 karolherbst: imirkin_: any ideas about "Mesa: User error: GL_INVALID_OPERATION in fragment shader does not allow advanced blending mode (GL_MULTIPLY)"? for odd reasons this test sometimes Passes and I don't know why
19:29 justaguy`: If you can find something cheaper that can drive 3 displays, that'd be awesome.
19:29 imirkin_: check how much GT 740's cost
19:30 imirkin_: the one i'm looking at is $100 with 3 digital
19:31 karolherbst: okay, if I simply remove that check, it works
19:31 justaguy`: So something like this? http://www.ebay.ca/itm/ASUS-NVIDIA-GeForce-GT-740-1GB-DDR5-RAM-384-CUDA-Cores-GT740-OC-1GD5-/172707915154?hash=item283631a592:g:qm8AAOSwR29ZMCa9
19:32 karolherbst: okay, I fix this blending thing first, would get us 34 Tests closer to 4.4
19:34 imirkin_: justaguy`: only 2 digital on that one
19:35 imirkin_: justaguy`: more like this: http://www.ebay.ca/itm/EVGA-GeForce-GT-740-Superclocked-2GB-GDDR5-PCIe-Dual-DVI-Video-Card-w-mini-HDMI-/371910453981
19:35 gnarface: just curious, is there a kernel version that supports G92 reclocking yet?
19:36 imirkin_: gnarface: no.
19:36 gnarface: drat :(
19:36 imirkin_: although if you desperately want to test stuff, you can try it. but it's much more likely to not work than to work.
19:36 imirkin_: i sent a bunch of G92's to RSpliet in vague hopes of that getting fixed up. not yet though :)
19:36 gnarface: i'm not that smart yet, but that day may yet still be coming
19:36 karolherbst: duh... I think I know what's wrong here
19:37 imirkin_: karolherbst: forgetting to set the upper bound of the register thing?
19:37 karolherbst: " ctx->FragmentProgram._Current;" is sometimes NULL for whatever reason
19:37 imirkin_: karolherbst: that should be ~impossible.
19:37 imirkin_: karolherbst: certainly for a draw.
19:37 karolherbst: well
19:37 karolherbst: it is only sometimes NULL
19:37 karolherbst: I am sure if I put a sleep in there, it's always !NULL
19:38 justaguy`: imirkin_: Thank you for all the help!
19:38 imirkin_: justaguy`: although the 650 might be better than that one, dunno.
19:39 gnarface: i dunno i have a 650 right now and it takes more cpu to play h264 video than my 560 did
19:39 karolherbst: ohh wait, no, prog is always !NULL, but prog->sh.fs.BlendSupport sometimes is 0
19:40 imirkin_: gnarface: shouldn't matter.
19:40 gnarface: (the "BOOST" in "650 BOOST" i think means it doesn't have hardware h264 decoding and uses the opengl chip instead?)
19:40 imirkin_: gnarface: pastebin 'vdpauinfo' output
19:40 gnarface: it matters by about 20% more cost of cpu load in low power mode
19:40 gnarface: (at 800Mhz)
19:40 karolherbst: DUH!!! no wait, please no
19:41 karolherbst: imirkin_: I think I know it...
19:41 karolherbst: guess
19:41 imirkin_: forgetting to copy the value?
19:41 imirkin_: shader cache?
19:41 karolherbst: well after a recompile it works once
19:41 karolherbst: then it fails on a second run
19:41 karolherbst: ;)
19:41 gnarface: imirkin_: although, i'm using the nvidia binary gunk on this, maybe you're right that it wouldn't matter for nouveau: http://paste.debian.net/980988/
19:42 imirkin_: oh goodie.
19:42 imirkin_: gnarface: ah, for nvidia, no clue
19:42 imirkin_: could be that your video player is making use of some of the video mixer features, like hq scaling/etc
19:43 gnarface: imirkin_: well it's mplayer, and i'm explicitly invoking vdpau, which noticably works, just not as well as it did on the 560
19:43 imirkin_: very surprising.
19:44 gnarface: imirkin_: binary drivers sandbagging performance indiscriminantly isn't out of the question, but i was lead to believe it's due to the fact there's a physical hardware h264 decoder chip, dedicated, in some models, while others (aka "BOOST" models for one) have that chip stripped out for cost saving.
19:44 gnarface: hmm.
19:44 gnarface: imirkin_: i thought you actually told me that, now i have no idea where i got that info
19:45 imirkin_: i have never heard of that
19:45 imirkin_: there were a handful of weirdo G86M chips with the video decoding stuff fused off, but i haven't seen it on anything more recent.
19:45 gnarface: i almost switched back to the 560 when i figured it out, but the 560 only had 1GB of video ram, so the 650 still wins out in performance with 2GB on most games. it just costs a little more load to watch video
19:45 imirkin_: NVS 140's, iirc.
19:46 imirkin_: although it's technically possible, and iirc we do look in the place that nvidia has for stuff being disabled, in which case everything would work fine
19:46 imirkin_: so we might just not be aware of it because we don't crash when that happens :)
19:47 imirkin_: and each one of us only has a tiny selection of hw compared to the global total
19:47 karolherbst: imirkin_: well I don't see the shader cache handling the blendSupport at all, no idea why it never fails on intel though
19:47 imirkin_: karolherbst: ping tarceri i guess?
19:48 gnarface: in nvidia-settings you can actually see on one of the tabs "gpu utilization" and "video engine utilization" readouts in % - on the 560, watching h264 video shows some value in video engine of like 20-80% depending (if i recall) with like 1% in gpu utilization. whereas on the 650, the same video stream shows 0% on video engine utilization at all times, but GPU utilization spikes to 40% and up right away
19:48 imirkin_: very weird.
19:48 imirkin_: do you have envytools installed?
19:48 gnarface: i do not
19:49 imirkin_: well, if you get it, run nvapeek 22500, and see if & 0x4 is set
19:50 gnarface: ah, is that the "video engine" bit?
19:50 imirkin_: (and/or bit 0x2)
19:50 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/devinit/gf100.c#L66
19:50 gnarface: hmm, interesting
19:50 imirkin_: MSVLD = variable-length decoding (i.e. bitstream parsing)
19:50 imirkin_: MSPDEC = actual video decoding
19:50 imirkin_: MSPPP = post-processing
19:51 imirkin_: MSENC = video encoding
19:54 gnarface: envytools is just userland stuff, doesn't modify the kernel or driver?
19:54 gnarface: or do i need to also be running nouveau to use envytools?
19:54 gnarface: (i know that's a dumb question and i'm sorry)
19:55 imirkin_: yea
19:55 imirkin_: just userland
19:55 imirkin_: works with nvidia
19:55 imirkin_: (kidna the reason for its existence)
19:56 gnarface: ok, so that's like their official hardware debugging toolkit or whatever?
19:56 mwk: it's our unofficial toolkit
19:56 mwk: + hardware info database + some scattered pieces of documentation
19:57 gnarface: gotcha
20:08 RSpliet: heh, okay... so imirkin_: don't bother with that patch set. Even if it's perfect, I just can't find a benchmark that confirms performance improvements.
20:09 imirkin_: RSpliet: :(
20:09 RSpliet: what I did find is Unigine Heaven at medium quality, moderate tesselation and 4xAA shouting
20:09 RSpliet: WARNING: out of code space, evicting all shaders.
20:09 RSpliet: and just after the benchmark
20:09 RSpliet: heaven_x64: pushbuf.c:727: nouveau_pushbuf_data: Assertion `kref' failed.
20:09 imirkin_: urgh.
20:10 imirkin_: the WARNING thing is fine and expected
20:10 imirkin_: if you have a lot of shaders, we'll run out of space eventually
20:10 imirkin_: the latter ... less-than-expected
20:10 RSpliet: yeah, and I bet Unigine has just that
20:11 RSpliet: the assertion was pseudo-random unfortunately... out of 2 runs with these quality settings (where I completely exited the program in between) I got it once
20:12 karolherbst: 0.979% :)
20:12 karolherbst: we are getting there
20:13 RSpliet: karolherbst: what is that percentage?
20:13 karolherbst: passing CTS 4.4 tests
20:14 imirkin_: failing, presumably...
20:14 imirkin_: otherwise you've got a looong looong road ahead
20:15 karolherbst: ohhh wait
20:15 karolherbst: 97,9%
20:15 RSpliet: passing, presumably...
20:15 karolherbst: yeah
20:15 karolherbst: 27 test failing which are not InternalError or NotSupported
20:16 imirkin_: InternalError really stinks
20:16 karolherbst: yes
20:16 karolherbst: I ignore those for now
20:16 imirkin_: a lot of those, or just a handful?
20:17 karolherbst: 7
20:17 imirkin_: ah ok
20:19 karolherbst: failing tests: https://gist.github.com/karolherbst/21c3cb5b88d5bc198d7f339b985f95b5
20:19 karolherbst: in a plain run "KHR-GL44.pipeline_statistics_query_tests_ARB.functional_tess_queries" passes though
20:21 imirkin_: those pipeline query statistics are annoying... i think that something "weird" is going on, since those things *basically* work
20:21 imirkin_: but ... not completely apparently.
20:22 imirkin_: [except the compute one - that one's known-broken]
20:22 imirkin_: KHR-GL44.pipeline_statistics_query_tests_ARB.functional_default_qo_values
20:22 imirkin_: the fact that that fails is telling though
20:23 karolherbst: this sounds like a nice test though
20:23 karolherbst: Invalid default non-QO BO int32 query result value: found [2147483647], expected:[0], query type:[GL_COMPUTE_SHADER_INVOCATIONS_ARB], GL_PRIMITIVE_RESTART mode:[disabled], draw call type:[(does not apply)], primitive type:[(does not apply)].
20:24 karolherbst: I guess we set somewhere -1 and such, which should be simply 0
20:24 imirkin_: anything with GL_COMPUTE_SHADER_INVOCATIONS - ignore.
20:25 imirkin_: that just totally doesn't work
20:25 karolherbst: ohh, I see
20:25 karolherbst: why not though?
20:25 imirkin_: why is the sky blue?
20:25 imirkin_: the code to make it work is just plain not there.
20:25 imirkin_: largely because we're not sure what the correct way is.
20:26 airlied: karolherbst: test clears to -1
20:26 airlied: imirkin_: no traces?
20:26 karolherbst: I think all those pipeline stats test failed due to
20:26 karolherbst: GL_COMPUTE_SHADER_INVOCATIONS
20:26 imirkin_: airlied: nvidia doesn't do so great at it either.
20:26 imirkin_: airlied: basically there's no "easy" way of getting the number, there's no counter
20:27 imirkin_: iirc the blob tended to segfault when you used it
20:27 imirkin_: at least when hakzsam was looking at it a whiel back
20:27 karolherbst: I check that
20:27 imirkin_: could be all better now for all i know
20:27 imirkin_: we also have problems with mmt and GL + compute pipelines
20:27 imirkin_: it gets all confused
20:27 imirkin_: (or rather, demmt)
20:28 imirkin_: none of which are excuses for not supporting it in nouveau, but ...
20:29 karolherbst: they all pass on nvidia
20:29 karolherbst: I think
20:29 karolherbst: not sure if nvidia libs are used
20:30 karolherbst: okay, nvidia is used
20:36 karolherbst: that "KHR-GL44.texture_cube_map_array.sampling" test is annoying, there are 720 tests, 144 fail, and the error is Invalid Result :/
21:22 karolherbst: copy image GL_RENDERBUFFER->GL_TEXTURE_2D_ARRAY for formats GL_RGB10_A2_EXT -> GL_R11F_G11F_B10F is a bit broken
21:22 karolherbst: not much
21:23 karolherbst: data: 0xc7f00000 vs 0xc7f00004
21:30 imirkin_: mmmmmm ... hrm
21:34 karolherbst: GL_R11F_G11F_B10F doesn't seem to be the issue, but GL_RGB10_A2_EXT
21:34 karolherbst: other tests with GL_R11F_G11F_B10F pass
21:37 imirkin_: hmmm... odd.
21:38 karolherbst: GL_RGB10_EXT -> GL_RGB10_EXT is also broken
21:38 karolherbst: 0x07f00000 vs 0xc8000000
21:39 imirkin_: oh wait... i'm not sure that GL_RGB10_A2 is well-defined
21:39 imirkin_: it can be RGB10A2 or BGR10A2
21:39 imirkin_: so any test with copy image on those formats can be wrong
21:39 karolherbst: I see
21:40 karolherbst: this line looks little odd, but maybe that's just me not knowing how that format thing works: C4(A, B10G10R10A2_UINT, RGB10_A2_UINT, B, G, R, A, UINT, A2B10G10R10, T),
21:41 imirkin_: mmmmm right
21:41 imirkin_: oh
21:41 imirkin_: T
21:41 imirkin_: texture only i think
21:41 imirkin_: no render
21:41 imirkin_: that second-to-last param should be NONE
21:42 imirkin_: but that's not the right format
21:42 karolherbst: for all with T?
21:42 imirkin_: the right format is _UNORM
21:42 karolherbst: BGR10_A2_UNORM?
21:42 imirkin_: yes
21:43 imirkin_: check piglit history for the copy image stuff
21:43 imirkin_: iirc some got nuked
21:43 imirkin_: hmmm... maybe it was for shader images?
21:44 karolherbst: okay, but it doesn't seem to be the real issue above
21:44 karolherbst: another line is causing issues already
21:45 imirkin_: that's telling... arb_copy_image/formats.c doesn't even have RGB10
21:46 karolherbst: "C4(A, R10G10B10A2_UNORM, RGB10_A2_UNORM, R, G, B, A, UNORM, A2B10G10R10, IB)" and "C4(A, B10G10R10A2_UNORM, BGR10_A2_UNORM, B, G, R, A, UNORM, A2B10G10R10, TD)" are causing the above mentioned error
21:46 karolherbst: would like to solve those first
21:48 imirkin_: oh wait, that second-to-last is the teture format. right.
21:55 karolherbst: okay, no I have no clue why GL_RGB10_EXT -> GL_RGB10_EXT is broken
21:56 karolherbst: or well, why it tests this at all
21:56 imirkin_: is it renderbuffer -> renderbuffer, or image -> image?
21:56 imirkin_: er, texture -> texture
21:56 imirkin_: errrrrr gr.
21:56 imirkin_: is it renderbuffer -> texture or texture -> texture
21:56 karolherbst: renderbuffer -> GL_TEXTURE_2D_ARRAY
21:56 imirkin_: ok
21:57 imirkin_: https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_format.c#n1109
21:57 karolherbst: 0x07f00000 vs 0xc000007f.
21:57 imirkin_: try changing the order of rgb vs bgr in the RGB10A2 list
21:57 imirkin_: yeah, this is the RGB vs BGR issue
21:59 karolherbst: okay, I did something wrong in changing stuff
22:00 karolherbst: { PIPE_FORMAT_R10G10B10A2_UNORM, PIPE_FORMAT_B10G10R10A2_UNORM, -> { PIPE_FORMAT_B10G10R10A2_UNORM, PIPE_FORMAT_R10G10B10A2_UNORM,
22:00 karolherbst: ohh wait, no
22:00 karolherbst: I tested something else
22:01 karolherbst: okay, again
22:02 karolherbst: renderbuffer -> texture for GL_RGB10_A2_EXT -> GL_R11F_G11F_B10F produces 0xc7f00000 instead of 0xc7f00004
22:04 karolherbst: renderbuffer -> texture for GL_RGB10_EXT -> GL_RGB10_EXT produces 0x07f00000 instead of 0xc8000000
22:06 imirkin_: that's odd. i dunno.
22:07 karolherbst: I can't disable the last one for some reason
22:10 karolherbst: the first one just looks super odd, as if the last/first 3 bits are totally ignored
22:12 luv: hi again :)
22:12 karolherbst: imirkin_: do you know what I need to do, so that RGB10_EXT isn't used at all? I think the test somehow checks what is supported or so, but I don't find it anywhere in the formats table
22:12 imirkin_: karolherbst: RGB10_EXT = RGB10
22:12 luv: just wondering - is it possible to find out what ram vendor a graphics card use without disassembling it?
22:13 karolherbst: imirkin_: ohh, the nouveau table doesn't list all, just "odd" ones?
22:13 imirkin_: nouveau table lists all
22:13 imirkin_: RGB10 isn't directly supported for rendering
22:13 imirkin_: you're looking for R10G10B10X2 btw
22:13 karolherbst: ahh
22:13 karolherbst: isn't there
22:14 imirkin_: and there's an outstanding issue with GL_RGB + blending with DST_ALPHA
22:14 imirkin_: er, GL_RGB10 + blending with DST_ALPHA
22:14 karolherbst: well okay, but R10G10B10X2 isn't listed in the table
22:17 karolherbst: anyway, it's getting late, will have much more time tomorrow for all this anyway
22:22 imirkin_: BGR10X2?
22:23 imirkin_: (yeah, i think there's no gallium RGB10X2 format for some reason)