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