00:36 imirkin: karolherbst: to confirm, you ran CTS with my latest patches including the levelZero one and all was well, yes?
00:36 imirkin: [except for the tests you reported as failing, which are unrelated to the levelZero thing]
00:36 karolherbst: imirkin: 1265ce677e74fe5dadfe4c3039e0ff2d92eb54cb is the top commit
00:37 karolherbst: should be the same as in your github repository
00:38 imirkin: ok great
00:38 imirkin: i'm going to push all of those other than the gallium/mesa ones then
00:38 imirkin: speak now if you object :)
00:39 karolherbst: imirkin: I think we want to have acks from others for the 1265ce677e74fe5dadfe4c3039e0ff2d92eb54cb commit
00:39 imirkin: yep
00:39 imirkin: that's under the "gallium/mesa" heading
00:40 imirkin: i.e. "other than those"
00:40 imirkin: but all the nouveau-internal ones
00:40 karolherbst: ohhh, true
00:40 karolherbst: okay, then that should be alright :)
00:40 karolherbst: I didn't test on kepler obviously
00:40 imirkin: yeah, don't worry about that
00:40 karolherbst: but I guess you did that
00:40 imirkin: i tested on kepler2
00:40 imirkin: it could theoretically break things on kepler1, but ... very unlikely
00:43 imirkin: i guess i could keep the gk104 rcp/rsq thing out, but again ... meh
00:43 karolherbst: that should be fine
00:43 karolherbst: I am sure I've tested it plenty of times
00:43 imirkin: yeah
00:43 imirkin: i made some changes to the source, but it didn't affect the generated asm (which is good)
00:43 imirkin: basically stuck "long" in a bunch more places where i thought it could potentially matter
00:44 imirkin: should have some #pragma long or something
00:44 imirkin: but ... there's better uses of time than that :)
00:53 imirkin: ok, so now i need to take that blit z32_s8 thing apart
01:02 imirkin: ok. this is VERY surprising. blitting from non-ms to 4x and 8x msaa = fail?
01:02 imirkin: that's the easiest blit of all
01:03 karolherbst: yeah...
01:04 karolherbst: but looking at the result the scaling is simply wrong
01:06 imirkin: yeah
01:06 imirkin: i'll have to think about it.
01:06 karolherbst: I mean, looking at it, my patch kind of make sense, but maybe there is more to it? dunno
01:07 imirkin: that stuff's not there randomly either
01:07 imirkin: i'll have to think about it
01:07 imirkin: in any case it needs a lot more justification than "fix weird MS issue" :)
01:08 karolherbst: I though that describes it perfectly :p
01:08 imirkin: the problem is that we cheat pretty hard in that blitter, esp when it comes to MS
01:08 joepublic: "perform bold, inventive optimizations for speed"
01:09 karolherbst: imirkin: I guess we could just port to u_blitter and forget about all of that?
01:09 imirkin: thing is that x0/y0/etc are scaled by ms_x/y
01:10 imirkin: but like i said ... let me think
01:11 imirkin: need to chekc how the 2 attribs are used again
01:11 imirkin: been a very long time
01:13 karolherbst: imirkin: thing is, I am sure that my patch neither triggered regressions inside piglit, nor the CTS :/
01:13 karolherbst: I think it even fixed a bunch of piglits tests as well
01:13 imirkin: that's great
01:14 imirkin: i'd still like to understand what's going on =]
01:14 karolherbst: sure :)
01:14 imirkin: perhaps it's doing the right thing
01:15 karolherbst: I'll be honest, I have no idea what's going on there either, it was just a lucky guess
01:15 imirkin: but it'd be a bit surprising given that the blit isn't 100% broken
01:15 imirkin: e.g. for color
01:15 imirkin: and then ... why is depth different than color, etc
01:15 imirkin: z32f_s8 blit is handled differently
01:15 imirkin: so perhaps it's the only one of "those" cases that hits this pipeline
01:15 karolherbst: probably
01:16 imirkin: and the rest go via the 2d engine
01:16 imirkin: since for single -> multiple samples, it's basically a 2d engine job
01:16 imirkin: you just broadcast the same value to all the samples
01:16 karolherbst: ohh, wait, yeah, I think there was this explicit check somewhere
01:16 imirkin: but z32f_s8 has to go through the 3d engine
01:17 imirkin: but then ... why does 2x work and not 4x? i guess it gets stretched along the y axis?
01:17 imirkin: anyways -- Needs Understanding (tm)
01:17 karolherbst: imirkin: hehe.. "if (info->dst.resource->format == PIPE_FORMAT_Z32_FLOAT || info->dst.resource->format == PIPE_FORMAT_Z32_FLOAT_S8X24_UINT) eng3d = true;"
01:18 imirkin: right.
01:18 imirkin: but it works for 2x
01:18 imirkin: and not 4x
01:18 imirkin: we over-rast it by A LOT
01:18 imirkin: i wonder if that's part of it
01:18 imirkin: i'm going to try making it a square instead of a triangle
01:21 imirkin: yeah ok
01:22 imirkin: it can't handle the giant rast values
01:22 imirkin: https://hastebin.com/doruraquni.md
01:22 imirkin: this also fixes it
01:22 karolherbst: mhh
01:23 imirkin: we draw this GIANT triangle
01:23 imirkin: that's guaranteed to cover the square that we actually want to rasterize
01:23 imirkin: but i think the values are a bit too big, and something gets screwed up
01:23 karolherbst: yeah... kind of makes sense
01:24 imirkin: we also do this without window transforms
01:24 imirkin: which is why these aren't the normalized coordinates
01:24 imirkin: they're the window coords
01:24 imirkin: the max fb size is 16x16k
01:24 karolherbst: doing that with a rectangle feels more natural anyway
01:25 imirkin: that's why we use a 32kx32k triangle
01:25 imirkin: so that the 16kx16k square fits inside
01:25 imirkin: however if there's MS, we have to use an even larger triangle
01:25 imirkin: which is why it's 32k << ms factor
01:25 imirkin: removing the ms factor will mean that a blit might not 100% cover the desired region
01:26 karolherbst: for really big blits I assume?
01:26 imirkin: for a super-large texture
01:26 imirkin: right
01:26 imirkin: for 256x256, nobody gives a shit
01:26 imirkin: the problem with a square is that it's 2 triangles separately rasterized
01:26 imirkin: let me do a poll to see what some other people do
02:06 imirkin: wait
02:06 imirkin: i think we can just safely drop those shifts.
02:06 imirkin: =]
02:09 imirkin: i need to do some tests.
02:13 karolherbst: meh.. those random channel kills are super annoying
02:16 imirkin: so i think all the dst-coord-related ms shifts are totally bogus in the 3d path
02:16 imirkin: on both nv50 and nvc0
02:16 imirkin: i'm going to do some tests to verify this
02:16 imirkin: but that's my current thinking.
02:16 karolherbst:is wishing we had any way to debug those CTXSW_TIMEOUTs
02:16 imirkin: karolherbst: well, i consistently get one on GK208 for that dEQP
02:17 karolherbst: I now have a list of 4-5 games triggering those quite randomly :/
02:17 karolherbst: and I am sure there are more out there
02:17 karolherbst: maybe apitrace might help? but from my experience, it never did
02:18 karolherbst: mhh, let me try that again actually
02:19 karolherbst:is happy he has his channel dead detection patches, so his machine just recovers :p
02:27 karolherbst: ohhh
02:27 karolherbst: that trace triggers a channel kill :)
02:27 karolherbst: nice
02:29 karolherbst: now hoping that qapitrace is happy with that situation
02:44 karolherbst: imirkin: it's a glDrawRangeElements call
02:45 karolherbst: binds two buffers: ELEMENT_ARRAY_BUFFER + ARRAY_BUFFER
02:46 karolherbst: then VetexAttribPointer with pointer = NULL
02:46 karolherbst: then drawRangeElements with pointer = NULL
02:46 karolherbst: uhm
02:46 karolherbst: indicies
02:49 karolherbst: imirkin: uniform vec arr[256] that should be alright, or not?
02:49 karolherbst: in a vertex shader
02:50 karolherbst: doesn't matter anyway
03:10 Delemas: imirkin, nouveau worked fine. Thanks.
12:16 imirkin: karolherbst: uniforms in shaders are fine. DrawRangeElements(NULL) is fine too -- it's actually an offset into the bound element array buffer.
12:57 karolherbst: imirkin: yeah, I wasn't wondering about the general thing, more like if you have some ideas what could get wrong there
12:58 imirkin: nothing specific to those
12:58 imirkin: those are very very very common things to do
12:58 karolherbst: mhh :/
12:59 imirkin: it's basically "how indexed draws work"
12:59 karolherbst: sure, but I am thinking of something like "too many indicies at once" or something stupid like that
12:59 imirkin: now, if it's drawing only a handful of indices
13:00 imirkin: out of a giant vertex buffer
13:00 imirkin: which is client-side
13:00 imirkin: then we have some optimizations for that case
13:00 karolherbst: it's more like thousends
13:00 imirkin: also if there are DOUBLE or FIXED attributes, we hit a fallback path
13:00 imirkin: (which is why i had to fix indirect draw for those)
13:01 imirkin: btw - were you able to get a clean webgl run in the end?
13:01 imirkin: (webgl cts)
13:03 karolherbst: ohh interesting, with lower clocks I get the timeout with earlier calls as well
13:03 karolherbst: mhhh
13:13 karolherbst: mhhh, maybe it is indeed a proper timeout and the firmware doesn't like that something takes as long? :/
13:30 imirkin_: your guess is at least as good as mine, probably better
15:50 imirkin_: karolherbst: pretty sure i asked, but i forget your answer if any -- have you been able to get a complete webgl cts run?
15:50 karolherbst: imirkin_: yes
15:50 imirkin_: did you have to do anything special on top of the fixes which are already upstream?
15:50 imirkin_: iirc you did it locally to speed things up considerably
15:50 karolherbst: I used my mt fixes patches to get it to be more relible
15:50 imirkin_: ok
15:51 karolherbst: and cloned the repo, yes
15:51 karolherbst: doesn't help much with long running tests, so the overall speed is equalish
15:51 karolherbst: but less timeouts
15:51 imirkin_: do you have to do something once you clone the repo? or just point the browser to file:///bla ?
15:51 karolherbst: some chromium flag for local file access
15:51 imirkin_: yeah, that sounds familiar.
15:51 imirkin_: ok thanks
15:51 karolherbst: --allow-file-access-from-files
15:52 imirkin_: thanks
15:52 imirkin_: skeggsb: ping
16:28 karolherbst: this is great... trying to bisect which gl call causes the channel to be killed, but apperantly everytime I get to something, it's some previous call, which was fine before :/
16:29 imirkin_: it's almost as if there was something non-deterministic going on...
16:30 karolherbst: thing is, it kind of is
16:30 karolherbst: but yeah, not 100%
16:30 imirkin_: well, fwiw i have a reproducible CTXSW_TIMEOUT
16:30 imirkin_: on gk208
16:30 karolherbst: here as well
16:30 imirkin_: (or at least NV106)
16:30 karolherbst: even an apitrace
16:30 imirkin_: with a simple deqp test
16:30 karolherbst: ohh
16:30 karolherbst: which one?
16:30 imirkin_: i posted about it earlier
16:31 imirkin_: primitives_generated_instanced iirc
16:31 imirkin_: i don't think it dies on other gens. i wouldn't be surprised if it were GK208-specific.
16:32 karolherbst: dEQP-GLES31.functional.geometry_shading.query.primitives_generated_instanced?
16:32 karolherbst: mhh, works here
16:32 imirkin_: yeah, i think you said that
16:32 imirkin_: probably some bit of card config left out
16:32 imirkin_: that's why i want skeggsb's help :)
16:33 karolherbst: well, I have around 4 reproducible timeouts :) but those are triggered by games, so a bit annoying to debug
16:33 karolherbst: I think even one or two in piglit?
16:33 imirkin_: what gpu are you on?
16:33 karolherbst: those 4 are from gm204
16:33 imirkin_: so we have no control over the firmware in anyc ase
16:34 karolherbst: exactly
16:34 karolherbst: doesn't have to be a firmware bug though
16:34 imirkin_: doesn't have to be
16:34 imirkin_: but more fun to assume it is :)
16:34 imirkin_: that way you can move on to the next problem
16:34 karolherbst: what's most surprising that with higher clocks, the first call to fail is a much later one :)
16:36 karolherbst: I tri to talk with nvidia about that... I mean, it cannot be that we have no means to debug those fails
16:36 imirkin_: were you going to try to upstream support for reclocking gm20x?
16:36 imirkin_: (or is it there already?)
16:36 karolherbst: at some point... I think the patches are unchanged since the last time I've posted those
16:36 karolherbst: just needs somebody to look at those
16:36 imirkin_: just a matter of getting skeggsb to pick them up...
16:37 karolherbst: I tried too many times, guess I've gave up
16:37 imirkin_: or send to airlied direct?
16:37 karolherbst: can't even remember which branch those are on :D
16:37 karolherbst: they are essentially just patches for the gentoo-sources packages... and I think there are there since a year or something
16:38 karolherbst: I think that is the branch? https://github.com/karolherbst/nouveau/commits/clk_update_v3
16:38 karolherbst: ohh wait, that's missing bits
16:38 karolherbst: probably that one: https://github.com/karolherbst/nouveau/commits/clk_to_upstream
16:41 karolherbst: yep, should be
16:42 karolherbst: imirkin_: that patch is golden btw: https://github.com/karolherbst/nouveau/commit/92be149a28e3e22fb20500f8a26f8b20c260d06d
16:42 karolherbst: otherwise we can't use the PMU to do memory reclocking :)
16:43 karolherbst: and maybe even wrong
16:43 karolherbst: dunno
16:43 karolherbst: works for me
16:54 karolherbst: mhhh...
16:54 karolherbst: I think we are hitting a real timeout here
16:56 karolherbst: is that annoying
17:00 karolherbst: imirkin_: do you know how to turn off instanced drawing inside gallium?
17:02 imirkin_: that kills GL 3.0
17:02 imirkin_: there's a PIPE_CAP for it... search for "instance"
17:02 imirkin_: or check what cap neables ARB_draw_instanced or something
17:02 karolherbst: mhh, yeah, I tried _INSTANCE and _INDIRECT but that doesn't really disable the extensions
17:02 karolherbst: maybe gallium emulates in such cases?
17:02 imirkin_: disable that
17:03 imirkin_: that'll kill everything
17:03 karolherbst: mhhhhhhhhh the channel kill is gone now with INSTANCE and INDIREC disabled :/
17:03 karolherbst: or uhm.. maybe it's a later call now...
17:03 karolherbst: let me verify
17:04 imirkin_: if you're just replaying the trace, you'll get errors for those draws
17:04 imirkin_: since it'll say "function not found" :)
17:04 karolherbst: well, I don't
17:04 karolherbst: ahh, still the channel timeout, okay, that's good
17:05 karolherbst: yep, instanceid is the right cap
17:06 karolherbst: still getting 3.0 though
17:06 imirkin_: erm
17:06 imirkin_: perhaps it's in 3.1? i forget.
17:06 karolherbst: yeah... sounds about right
17:06 imirkin_: i htought it was 3.0 tho
17:06 karolherbst: draw_instanced is 3.1
17:06 imirkin_: ah no. it's in 3.1. and ARB_instanced_arrays is in 3.3
17:07 imirkin_: (instanced arrays lets you have dividers)
17:07 imirkin_: or ... somethin
17:07 karolherbst: okay... so does the game run with 3.0...
17:08 karolherbst: it's a dx9 based one, so I guess they have fallback paths
17:08 imirkin_: should yeah
17:08 imirkin_: i don't think dx9 had any of that
17:08 imirkin_: that's all dx10 stuff
17:09 karolherbst: fun... still a dead channel
17:10 karolherbst: they do some query stuff though
17:10 karolherbst: I think I decide to blame that
17:11 imirkin_: wise choice.
17:11 karolherbst: I think when I gdb into it, it was hanging on fetching a query result actually
17:11 karolherbst: how can I disable all that?
17:12 imirkin_: queries? those are necessary for DX9
17:12 imirkin_: PIPE_CAP_OCCLUSION something
17:12 imirkin_: iirc needed for GL 2.0 or 2.1
17:12 karolherbst: well... one way to find out
17:13 karolherbst: yeah.... getting 1.4 now
17:13 HdkR: Hard code it to return zero :P
17:13 karolherbst: it makes like heavy use of it
17:13 karolherbst: fetches like 50 results each frame
17:14 karolherbst: mhhhhhhh
17:14 karolherbst: that's not it either
17:14 karolherbst: trace still replays fine
17:14 imirkin_: do you get a 2.0 or 1.x context now?
17:14 karolherbst: 1.4
17:14 imirkin_: =]
17:15 karolherbst: the channel is killed a bit later into the trace though
17:15 karolherbst: I guess it's gdb time
17:16 karolherbst: yeah, nice, X freezes of course. so remote gdb
17:24 karolherbst: what an annoying issue
17:25 karolherbst: mhhh nouveau_scratch_data
17:26 karolherbst: okay... so where is that bo used
18:56 karolherbst: imirkin_: mhhhh, user vertex buffer not flushed correctly? this could cause stuff like that I guess. It's essentially the most common thing that game does
18:57 karolherbst: well, user vertex buffer
19:06 imirkin_: "user"?
19:06 imirkin_: you mean client-side?
19:07 karolherbst: uhh, yes
19:07 imirkin_: those are a bit different on maxwell+
19:08 imirkin_: we have to stick them into a vbo
19:17 karolherbst: mhh, interesting
19:17 karolherbst: might be worth checking if we have the same issue on kepler
20:07 karolherbst: buuh ... :/
20:09 karolherbst: imirkin_: apperantly making vbos sysmen only helps...
20:09 karolherbst: uhm
20:09 karolherbst: or VERTEX_BUFFER... whatever that corresponds to
20:09 karolherbst: removed "BIND_VERTEX_BUFFER | BIND_INDEX_BUFFER" from the vidmem_bindings bitfield and now it doesn't kill the channel... didn't check if it's either of one, but...
20:12 karolherbst: yeah... seems like to be the VERTEX_BUFFER part of it :/
20:12 karolherbst: *sigh*
20:35 karolherbst: noo :/
20:35 karolherbst: imirkin_: this seems to fix it for other games as well
20:36 imirkin_: heh
20:36 imirkin_: solution: never use vram :)
20:37 karolherbst: annoying :/
20:37 karolherbst: I guess for vertex buffers it doesn't matter as much
20:37 karolherbst: but still
20:37 imirkin_: my guess is that we're missing a stall or smoething? dunno
20:37 RSpliet: VRAM is prohibitively slow anyway. *waves his fist at NVIDIA* damn you and your signed PMU firmware
20:38 imirkin_: or perhaps having to fetch from sysmem slows things down enough that it doesn't hit the badness it otherwise does :)
20:38 karolherbst: mhhhh
20:38 karolherbst: doubtfully
20:38 karolherbst: or maybe
20:38 karolherbst: dunno
20:41 karolherbst: but generally it felt like things are generally faster
20:41 karolherbst: with vertex buffers inside sysmem
20:42 imirkin_: lol
20:42 imirkin_: we're clearly doing a real-good job
20:42 imirkin_: the driver's so fast, that pcie to ram is faster than vram.
20:48 karolherbst: mhh, actually, it is a bit slower, but not _that_ much
20:49 karolherbst: 70 -> 63 fps in the game
20:49 karolherbst: just hard to check as the context just instantly goes down :/
20:52 karolherbst: imirkin_: any wild guesses on what the problem actually might be?
20:53 imirkin_: well ... with client buffers
20:53 imirkin_: we have to copy it SOMEWHERE
20:53 imirkin_: before we can hand it to the gpu
20:53 imirkin_: pre-maxwell, we essentially copy into pushbufs
20:53 imirkin_: since those GPUs have ways of consuming immediate-mode vertices like that
20:53 imirkin_: maxwell dropped those methods
20:54 imirkin_: which means that we have to stick them into a bo
20:54 imirkin_: i believe we use nouveau_scratch to get a bo to stick them into
20:54 imirkin_: that will get you a sub-allocated bo, potentially, which can have more stalls and whatnot
20:57 karolherbst: yeah, I saw that the application waits for the fence inside nouveau_scratch
20:59 karolherbst: I guess it might be a good idea to allocate anew bo instead and try with that?
20:59 imirkin_: it cuts both ways
20:59 imirkin_: if you have like 4 vertices
20:59 imirkin_: the overhead will become huge
21:05 karolherbst: maybe we could try if it helps if we only do it for many vertices
21:06 karolherbst: but... why would that be a problem in the first place
21:07 imirkin_: perhaps it doesn't like changing VBO's without some kind of flush?
21:16 karolherbst: mainly wondering what would be cheap to try out
22:11 karolherbst: imirkin_: mhhh, it seems to help with other games as well... oh well, at least we found _one_ reasons that is happening
22:17 imirkin_: you mean it helps perf? or it helps to not have hangs?
22:17 karolherbst: not having hangs
22:18 imirkin_: that's unfortunate.
22:18 karolherbst: which I kind of prefer of having more perf to be honest :/
22:18 imirkin_: hehe
22:18 imirkin_: can you specify a domain when getting scratch memory?
22:18 imirkin_: i forget how that api works
22:18 karolherbst: mhh, so you want to use sysmem only for the user stuff?
22:19 gnarface: i'm just watching along and trying to understand concepts here, so please forgive me if this is a dumb question, but can't you just save performance by stuffing a bunch of vertexes into one VBO?
22:19 imirkin_: yeah, but keep "real" vbo's in vram
22:19 imirkin_: gnarface: we don't control how the game is written
22:19 gnarface: oh, that's up to the game engine?
22:19 gnarface: hmmm, interesting
22:19 imirkin_: VBO = Vertex Buffer Object
22:19 imirkin_: which is a GL concept
22:19 karolherbst: gnarface: well, they stuff thousends of vertices inside such a user provided buffer
22:20 karolherbst: and we kind of have to deal with that
22:20 imirkin_: GL also enables you to have this data in client-side buffers
22:20 imirkin_: and some software (esp older software) avails themselves of that functionality
22:20 imirkin_: [esp since there were no VBO's back then, so there wasn't much choice in the matter]
22:20 imirkin_: although VBO's are fairly old...
22:20 imirkin_: but i don't think they became core until like GL 2.0
22:22 gnarface: i think quake2 and quake3 could use them for lighting under non-default options
22:22 gnarface: default was lightmap based (basically transparent bitmap lighting)
22:22 imirkin_: there's probably also multiple levels of this stuff
22:22 imirkin_: a long long time ago, you had immediate vertex data submission
22:23 imirkin_: i.e. glBegin(); glVertex4f(); glVertex4f()..... glEnd()
22:23 imirkin_: and then you could put that into buffers, which were either client- or gpu-side
22:23 gnarface: hmmm
22:23 imirkin_: and then you eventually got VAO's which could save a lot of configuration data about which attributes were where
22:23 imirkin_: (Vertex Array Objects)
22:23 imirkin_: at the gallium level, it's a lot simpler though
22:24 imirkin_: basically you get vertex data
22:24 gnarface: ah, i may have gotten VAO and VBO terminology confused
22:24 imirkin_: which may either be in a user buffer or a gpu buffer
22:24 imirkin_: if it's a user buffer, it's on you to get that to the gpu
22:24 imirkin_: (you = the driver)
23:39 karolherbst: imirkin_: ohh btw, I reworked how we collect our shaders in the shader-db. all files are nicley hashed now + I wrote a script to do the magic, so now one just have to collect the shaders inside shader-db/$game, run the script and then git tells you which new files there are (and removes all the duplicates)
23:40 karolherbst: nice for collect many shaders to do compile testing
23:47 karolherbst: imirkin_: uff, the scratch stuff is already inside GART uncondtionally :/
23:47 imirkin_: ok, that's not extremely surprising
23:51 karolherbst: using VertexAttribPointer with an array_buffer means that it's not doing the user memory stuff, right?
23:51 imirkin_: don't think so
23:51 imirkin_: depends on what's bound to ARRAY_BUFFER
23:52 imirkin_: erm
23:52 imirkin_: hrm. dunno. would have to look/think
23:52 imirkin_: :)
23:53 karolherbst: okay.. kind of looks like it looking at the trace
23:53 karolherbst: which changes our question/problem
23:57 gnarface: hmmm. i remember an old issue (in wine i think?) about performance sometimes being affected by a variable that forced hardware or software "vertex buffer arrays"... so this is why that sometimes helped performance, but sometimes did nothing, isn't it?
23:58 imirkin_: could be 1000 things
23:58 imirkin_: depends on precisely what that setting did
23:58 gnarface: hmm. i wish i remember where and when i was messing with it...
23:58 gnarface: i thought it was a wine thing
23:58 gnarface: i could be wrong
23:58 imirkin_: could be
23:58 imirkin_: but then it'd depend on what wine did differently :)
23:59 gnarface: yea, well that's often a thing with wine, is figuring out if what it's doing is even sensible to begin with