01:00 imirkin: karolherbst: heh, maxwell failed there because of an odd change i through into the levelZero change -- one to avoid adding constraint mov's for NOP's
01:00 imirkin: i'm going to split that out
01:01 imirkin: and fix it up separately
01:05 imirkin: karolherbst: updated tree -- https://github.com/imirkin/mesa/commits/cts2
01:06 karolherbst: cool
01:06 imirkin: doesn't have the st/mesa or gallium changes, and doesn't have the non-working 3d image thing for maxwell
01:10 imirkin: i'm gonna do a bit more testing in a bit, and then push those out.
01:11 imirkin: if you could do some quick tests as well, that'd be great. i esp want to make sure i didn't break texturing on maxwell+
01:44 imirkin: karolherbst: btw, i'm going to take your MAX_VARYINGS patch and send it out, along with the GL_RGBA4 == render one
01:44 karolherbst: imirkin: okay, sounds good
01:44 imirkin: i'd like to get those in sooner rather than later
03:05 imirkin: karolherbst: are you planning on giving the current patchstack a run of any sort?
03:06 imirkin: i'd like to get confirmation that the current "levelZero" fix commit doesn't break things on maxwell+
03:47 imirkin: woohoo! i got the black squares in chromium!
03:47 airlied: imirkin: as in reproduce the bug or the fix? :)
03:47 imirkin: reproduce is a strong word
03:47 imirkin: they're gone again
03:47 imirkin: but it's literally the first time i've seen them
03:48 imirkin: airlied: afaik the changes i pushed wrt not using old code pages in the presence of lots of contexts and shaders should help with that issue
03:48 imirkin: but my system install doesn't have that fix
03:54 imirkin: karolherbst: no reason we can't reuse basically the same code for fermi from your gk104 one, right?
03:54 imirkin: [for fp64 rcp/rsq]
04:00 imirkin: noooooo! KHR-GL45.gpu_shader_fp64.builtin.inversesqrt_double fails
04:01 imirkin: probably related. ok
04:03 imirkin: heh.
04:03 imirkin: info->io.fp64 = true -- only gets set to true when there are real fp64 ops
04:03 imirkin: not calls to external functions
04:15 imirkin: alrighty, let's try this again shall we
04:16 imirkin: Passed: 659/659 (100.0%)
04:16 imirkin: much better
07:38 imirkin: pendingchaos: after a lot of silly macro engine bugs, looks like i got it to work -- https://github.com/imirkin/mesa/commit/bef3494000c94bf2a3237d36ba044c66a48ec131
07:39 imirkin: only tested on GK208, so perhaps the same issue you mentioned will happen on other GPUs
07:50 HdkR: imirkin: woo!
08:07 HdkR: imirkin: Seems like the MME needs a multiply unit and native support for indirect compute invocation
11:04 karolherbst: imirkin: mhhh, so that tex flush thing didn't fix it :/
11:13 karolherbst: imirkin: but don't worry... I found a game yesterday with other flushing/caching issues :p
11:22 karolherbst: imirkin: so your current branch makes piglit not sad (1265ce677e74fe5dadfe4c3039e0ff2d92eb54cb)
11:23 karolherbst: running the CTS here as well to check what's missing
12:11 karolherbst: imirkin: three fails: KHR-GL45.packed_depth_stencil.blit.depth32f_stencil8, KHR-GL45.shader_image_load_store.non-layered_binding and KHR-GL45.tessellation_shader.single.xfb_captures_data_from_correct_stage
14:29 imirkin: karolherbst: cool. that's expected.
14:30 imirkin: karolherbst: non-layered_binding is the 3d image thing, xfb_captures_data_from_correct_stage is a mesa bug - there's a fix on list but it's not ideal
14:30 imirkin: karolherbst: and blit.depth32f_stencil8 is ... to be investigated. probably tonight. i see that fail too, just haven't gotten to it.
14:30 imirkin: HdkR: yeah, lack of multiply is a bitch
14:31 imirkin: HdkR: but the actual execution of indirect compute happens without macro engine involvement on kepler+
14:31 karolherbst: imirkin: I think that was fixed with that MS thingy patch... need to check but one of my patches fixed that as well
14:31 imirkin: karolherbst: yeah, i saw your patch. but i don't think it's right. i need to study the issue a bit more.
14:32 karolherbst: yeah... something is odd there
14:53 imirkin: it might be time to get started with getting the official khr status going
14:53 imirkin: i have a @x.org email that i can use to sign up there
14:53 imirkin: but i haven't actually gone through with it
15:13 karolherbst: imirkin: I have the account already
15:13 karolherbst: but you don't really need anything from there, just to submit the resulsts
15:13 imirkin: karolherbst: there's a separate CTS repository as i understand
15:13 karolherbst: not anymore
15:13 imirkin: with the GTF tests?
15:14 imirkin: or are those all upstream and/or deleted?
15:14 karolherbst: the open source one is enough
15:15 karolherbst: what's important that we kind of test against a proper release I think? maybe we can also just use master, but the non public ttests aren't required anymore
15:15 karolherbst: there was some documentation update on the CTS a while ago
15:15 imirkin: ok
15:15 imirkin: i like it :)
15:16 imirkin: anyways, i want to get all this stuff landed
15:16 imirkin: and then i'll have a look
15:16 karolherbst: right, but we have to support robust contexts
15:16 karolherbst: not that the CTS has any way to test it
15:16 karolherbst: but they check if we can create a robustness context
15:16 karolherbst: we can either just report we support that without being actually able to tell if the context is dead or recovery the context
15:16 karolherbst: either way is fine
15:17 imirkin: ok. i'll look into what's required.
15:17 karolherbst: either way requires kernel changes
15:19 imirkin: we'll see...
15:19 imirkin: either way, my next order of priority is that blit z32_s8 failure, and then generating some more variants to try on maxwell for the layered 3d thing
15:19 karolherbst: there are essentially two strategies LOSE_CONTEXT_ON_RESET_ARB (mark the gl context as dedad by returning that error code I don't remember on every gl call) or NO_RESET_NOTIFICATION_ARB (where we have to recover from any hw fault)
15:20 imirkin: karolherbst: LOSE_CONTEXT_ON_RESET should be easy enough -- any time a draw call fails, mark the context lost
15:20 karolherbst: how do we know it fails?
15:21 imirkin: the return value != 0?
15:21 karolherbst: so essentially wait for that timeout
15:21 karolherbst: that timeout is way too long anyway
15:21 imirkin: well, there's different types of failures
15:21 imirkin: and we don't have to do a good job - just pass the tests :)
15:21 karolherbst: I've implemented all that more or less properly anyway, the biggest issue is just that we don't really have a way to report it from pushbuffer kicks
15:22 karolherbst: not yet at least
15:22 karolherbst: yeah.. passing the tests is trivial
15:22 karolherbst: they only check if the context was created successfully
15:23 RSpliet: karolherbst: What's the status on threading btw?
15:24 karolherbst: needs testing and nv50/nv30 have to be finished
15:25 imirkin: karolherbst: i'm looking for a box-ticking exercise here... it's a hurdle we need to get over. doing it well would be nice too, but nto required for this particular step.
15:25 karolherbst: right
15:25 karolherbst: we can just expose that extension
15:25 karolherbst: sure
15:27 karolherbst: we basically just have to add stub implementations for set_device_reset_callback and get_device_reset_status
15:27 imirkin: k
15:29 karolherbst: but I've already done some work on detecting dead channels.. the only problematic part is it really doesn't fit well with the current structs we have
15:29 imirkin: yeah, i think that's great
15:29 imirkin: however not required for this particular thing...
15:30 karolherbst: not really, right
15:46 RSpliet: karolherbst: do we have good conclusive tests? What hardware needs testing for?
15:46 karolherbst: RSpliet: fermi+
15:47 RSpliet: +? as in... it needs testing on everything?
15:47 karolherbst: maybe? I am sure those patches are generally fine, I use them on my maxwell2 for quite some time
15:47 karolherbst: but.. random issues could mean I messed up something
15:47 RSpliet: Fermi in my experience is rather unstable, even with normal single-threaded operations
15:48 karolherbst: and there is that as well
15:48 RSpliet: I guess if you have a good way of testing I could very easily give them a spin on GK107 over the weekend or so
15:48 karolherbst: I don't
15:49 karolherbst: there are a few mt related issues we have, but there is no list of applications doing multi context stuff sadly
15:49 karolherbst: I've put some into the cover letter
15:50 karolherbst: some android-x86 also reported that my patches seem to make things way more stable than imirkin patches back then did
15:50 karolherbst: *android-x86 devs
15:51 imirkin: my patches were not going to work, which i told them, and they used them anyways
15:51 RSpliet: I don't think I'm subscribed to a mesa-dev ML. The nouveau one is noisy enough as-is, I'd just end up ignoring even more information :-p Do you have a branch and/or patchwork link?
15:52 RSpliet: imirkin: Do you have any thoughts on relatively trivial tests I could run to stress-test threading?
15:53 imirkin: mmmmmm
15:53 imirkin: well, you need a semi-complicated GL program
15:53 karolherbst: dolphin-emu
15:53 imirkin: one that uploads data, changes things, etc, and then draws
15:53 imirkin: and then do that in 100 threads
15:53 karolherbst: but you have tom compile it yourself
15:54 karolherbst: but dolphin only compiles
15:54 imirkin: dolphin is not a complicated GL program in that sense, i think
15:54 karolherbst: and does a VBO upload :D
15:54 imirkin: it doesn't try to break the underlying GL threading logic
15:54 karolherbst: right, but it triggers crashes nonetheless
15:54 imirkin: it only does it by accident :)
15:54 imirkin: i think RSpliet is looking for a program that *tries*
15:54 karolherbst: yeah... I have a list
15:54 imirkin: RSpliet: there's a piglit that does perf tests of draws/second in the presence of various state changes
15:54 karolherbst: https://patchwork.freedesktop.org/series/53595/
15:55 imirkin: i think something like that would be good, when run multithreaded
15:55 karolherbst: there are some leftover crashes though... minecraft apperantly and android-x86 still sees issues
15:55 karolherbst: would like to figure those out as well
15:56 karolherbst: I think I know why minecraft crashes though
15:56 karolherbst: if multiple threads doing screen only operation, then that's not gonna work that great either
15:56 karolherbst: with some gallium callback we don't know from which context those were triggered
15:56 RSpliet: imirkin: well, a unit test is obvs the easiest, but I can see why there's no deterministic test case for testing whether random thread interleavings are broken
15:57 imirkin: ;)
15:57 imirkin: RSpliet: have a look at that perf test that's in piglit somewhere
15:57 imirkin: iirc "drawoverhead"
15:57 imirkin: i think it could be adapted to being a threading stress test
15:57 RSpliet: imirkin: I guess I could try and run it unpatched first and see if the MTTF is acceptable
15:57 RSpliet: acceptable being acceptably low
15:58 imirkin: not acceptably high? :)
15:58 RSpliet: that would be after patching :-P
16:00 RSpliet: I recall having VirtualBox booting a 3D accelerated VM would lead to fairly reliable crashing, and that wasn't Windows' fault for a change. I thought the reason was threading related. I guess I should/could test that as well.
21:34 Delemas: I'm unfortunately stuck with an abandoned NVIDIA Corporation NV44 [Quadro NVS 285]. Is there any hope of getting this working properly with nouveau on Ubuntu 16.04 (and eventually 18.04)?
21:40 imirkin_: what's the issue?
21:45 Delemas: Binary driver abandoned it leaving me with a kernel that can't update. I either have to get nouveau working with it or buy a new card. Nouveau didn't like the card back when I first installed it.
21:46 Delemas: Otherwise I never would have installed the binary driver...
21:48 Delemas: I guess there is one way to find out. Anything is better than a kernel that won't build...
22:01 imirkin_: my question is ... what's the issue with nouveau on that gpu?
22:01 imirkin_: i was using a NV42 the other day, worked fine
22:02 imirkin_: as for specific versions of software shipped in specific distros, unfortunately i won't be of much help
22:07 Delemas: It was a very long time ago and has been upgraded many dists since then. It's just a server. It simply needs a working X console. I believe it was having issues displaying the native resolution of the monitor.
22:08 Delemas: It's just a simple Asus 1080p flat panel nothing exotic.
22:09 imirkin_: i'm sure that's fine
22:09 imirkin_: the problem might be more in the environment you're trying to run on it
22:09 imirkin_: which tries to use 3d accel to render buttons.
22:09 imirkin_: anyways, it should all work fine
22:10 imirkin_: if you have specific issues, feel free to report them
22:10 Delemas: It's a basic XFCE setup.
22:11 imirkin_: ok
22:11 imirkin_: not sure what you're looking for
22:11 imirkin_: like i said - it should all work fine
22:11 imirkin_: if you have concrete problems, we can investigate
22:11 imirkin_: otherwise there's not a whole lot that can be done