15:45karolherbst: tagr: do you know anything about the 2d class? I have the problem that the blitter _always_ starts copying from 0,0,0 even with absurd scaling applied. Like I have this one tests where it expects the value from 1,0,0 to be copied to 0,0,0. If I offset the src.x coord by 1 it all gets scaled correctly
15:45karolherbst: any ideas?
16:14tagr: not sure if I understand correctly... <0, 0> is going to remain <0, 0> irrespective of the scaling factor, right?
16:14tagr: what's the third coordinate? depth?
16:17karolherbst: tagr: soo.. there is this vulkan tests copying a 64x1x1 region into a 16x1x1 destination
16:18karolherbst: but it expects to find 1, 0, 0 from the source inside 0, 0, 0 in the dest
16:18karolherbst: so I configure it with a du_dx value of 4
16:19karolherbst: this is what I have: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/da674c1d49e5f5aa52693e86cc595a353ba0c571
16:19karolherbst: if I do a src_start.x += 1 it mostly works, but fails on later pixels
16:20karolherbst: filter is VK_FILTER_NEAREST
16:21karolherbst: legal values would be from 1,0,0 or 2,0,0 which kind of makes sense
16:22karolherbst: tagr: anyway, if you got _any_ idea on what might be wrong, that would be very helpful, because it seems to work in general, just some pixels are off :(
16:23karolherbst: although maybe it does ignore SET_PIXELS_FROM_MEMORY_SAMPLE_MODE for whatever reason...
16:32tagr: hmm... where's the documentation for this?
16:32karolherbst: well.. we don't have any :)
16:33tagr: ah... https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/twod/cl902d.h
16:33karolherbst: tagr: this is all we got https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/twod/cl902d.h
16:33tagr: doesn't seem all that helpful
16:33karolherbst: stills hows what's there
16:33karolherbst: the list of formats is very helpful e.g.
16:33karolherbst: but yeah...
16:33karolherbst: I essentially copy over what we do in gallium
16:33tagr: so looking at some reference code it seems like the SET_PIXELS_FROM_MEMORY_SRC_* format is different from the DST_* fields
16:34tagr: DST coordinates seem to be in 32.32 format
16:34karolherbst: dst encode start + size
16:34karolherbst: src encodes start + scaling
16:35tagr: I'm looking at an example that seems to be 36.28 or something
16:35tagr: or maybe it's 28.4
16:36karolherbst: you are right
16:37karolherbst: srcx = (int64_t)(info->src.box.x + srcx_adj) << (src->ms_x + 32)
16:37karolherbst: ehh wait
16:37karolherbst: that's fine
16:37karolherbst: I already do this part... mhhh
16:37karolherbst: anyway.. it feels like that just the filtering part is bonkers
16:38tagr: the SRC_X0_FRAC method, for example, I see that encoded as (start_x & 0xf) << 28 and SRC_X0_INT as start_x >> 4
16:39karolherbst: let me try that
16:41karolherbst: doesn't change anything
16:42karolherbst: tagr: how is that du_dx/dv_dy stuff calculted, any different from what I do?
16:43tagr: oh... I suppose the masking/shifting is because there's a 1 << 4 scale factor in there for some reason
16:43karolherbst: yeah.. I expected something like that :)
16:54tagr: hm... nope, can't spot anything wrong with your code
16:54tagr: though I'm not an expert in TWOD at all
16:54karolherbst: I am sure there is some global flag _somewhere_ enabling/disabling the sampling stuff
16:55karolherbst: because it appears it just takes the left value
16:55tagr: you don't set SET_PIXELS_FROM_MEMORY_DIRECTION, but I guess the default may be the right one?
16:58karolherbst: we don't set it ever in gallium
16:58karolherbst: yeah.. anyway
16:58karolherbst: the scaling and all of that works
16:58karolherbst: it just takes the wrong value
16:59karolherbst: 0 -> 0, 4 -> 1, 8 -> 2, 12 -> 3 etc...
16:59tagr: isn't that correct, though?
16:59karolherbst: it isn't
16:59karolherbst: I want nearest filtering
16:59tagr: why not? if you scale down by 4 you take every 4th pixel, starting with 0
17:00karolherbst: well vulkan expects 1/2 -> 0, 5/6 -> 1, 9/10 -> 2, etc...
17:00tagr: not sure what SAMPLE_MODE_FILTER == POINT means
17:01karolherbst: yeah... the other values make no difference anyway
17:01tagr: there's only one other, which is BILINEAR
17:01karolherbst: there is also ORIGIN_CENTER vs ORIGIN_CORNER
17:01karolherbst: which sounds more relevant to this issue
17:01karolherbst: it appears to always do ORIGIN_CORNER, but I want CENTER?
17:01karolherbst: I think?
17:01tagr: SAMPLE_ORIGIN_CENTER also makes sense for nearest, I'd say
17:02karolherbst: CORNER did something
17:02karolherbst: just not at 0,0,0
17:05tagr: I wonder if perhaps you need to adjust the src_start.x and push it into the center of your source pixel
17:05karolherbst: maybe that was BILINEAR vs POINT
17:05karolherbst: anyway, it looks like I want point
17:05karolherbst: but CORNER vs CENTER doesn't make a difference wiht POINT
17:05karolherbst: tagr: sounds like something you could run into out of bound troubles really quickly :P
17:06karolherbst: but maybe?
17:06karolherbst: I think the hw complains though...
17:07karolherbst: src_start_x + 2 does something interesting
17:07karolherbst: now it maps 2 to 0, okay.. that's sounds okay
17:08tagr: I think you'd want something like src_start.x + du_dy / 2 to move this to the middle
17:08tagr: du_dx / 2, even
17:08tagr: well, I guess also adjust for the << 32
17:08tagr: so src_start.x + du_dx >> 33?
17:09karolherbst: but yeah.. seems like moving it helps
17:09karolherbst: this is weird
17:09karolherbst: maybe gallium is doing magic behind our backs? I have no idea
17:09karolherbst: we don't do any of that in nvc0
17:09tagr: it does make sense, though, somehow
17:11karolherbst: we do center it for MS though
17:17tagr: I think you want CENTER/BILINEAR for downscaling and CORNER/POINT for upscaling
17:17tagr: that is, /if/ I understand this correctly
17:18tagr: anyway, I need to drop off
17:18karolherbst: k, thanks for your help
17:19tagr: hope you can figure out the rest
17:19karolherbst: I hope so as well :D
17:19tagr: I'll be AFK for most of the rest of the week, so not sure how much I can help, should be back to normal starting Monday, though
17:20karolherbst: mhh Passed: 1/1 (100.0%)
17:20karolherbst: I hate it, but if this is what it takes :D
17:21tagr: the more I think about it, the more it makes sense, though
17:21tagr: I mean if the hardware doesn't do the subsample offset, you've got to do it manually
17:21karolherbst: it was probably pointless to add it to hw if it can be done in sw easily
17:22tagr: yeah, especially if you want to stay flexible to cope with whatever some standard might dream up
22:45karolherbst: tagr: my brain melts https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/bcd00544eee4fdc4f7a6c8ffa27f8314258e66c4
22:46karolherbst: but it does work...
22:46karolherbst: linear, nearest.. mirrored on none, one or two axis... doesn't matter
22:47karolherbst: upscaling, downscaling...