00:18 bnieuwenhuizen: true
00:19 bnieuwenhuizen: should probably start with prolog/epilog and/or shaders without spec constants though
03:32 hanetzer: agd5f: so. I've found another oddity. Apparently this same hw cfg (rx 5700 xt) is not able to drive a tiled display in windows 10 either. Furthermore, lack of some form of efi driver, in either the vbios or the motherboard's uefi firmware prevents output pre-os (bios/uefi, bootloaders, etc), and only 'come up' once linux or windows boots.
05:34 randymago: karolherbst: I do not know your age, and earlier luck for getting the momentum and effort done , atm. in sanity AMD programmers hold a minor lead and even the xilinx almost full PLL implementation is posted to the web. Currently nha and tsellard stucture their thoughts better, but you have any chanche present to close the gap or lead if you have some power or strenghts left. Me for instance i simulated the dispatcher and every circuit and did that
05:34 randymago: allready.
05:44 randymago: if someone wants i can show the gtkw and vcd of that inexpensive minor effort, iverilog and gtkwave was used ontop of miaow, but nha and tstellar knew this how it works allready in 2015 according to dri-devel logs, so do not worry every chanche is provided for people who have interest.
05:59 randymago: in particular just like they said, dispatcher chooses on such simd archs, whether the wavegroups have multiple wavefronts or not.
05:59 randymago: i.e if instructions are dependent on each other, so it feeds proper VGPR_BASE to the circuit-
10:25 jock: Hello all, don't know if this is the right place to ask for help, that's the first time I mess with the kernel and DRM
10:27 jock: I made a little patch to add the hardware cursor plane to some rockchip SoCs. Support was removed some time ago: https://www.spinics.net/lists/dri-devel/msg85289.html
10:30 jock: Starting from that old patch I made this one: https://pastebin.com/An0tLLYu that is restoring the hwcursor. It works very well, the cursor appears on screen and colors are right. The hotspot also is set right, but of course it has limited sizes (32x32, 64x64, 96x96 and 128x128)
10:34 jock: The only issue is that when the cursor is moved to the extreme left it goes outside the display viewport of a couple of pixels on the horizontal coordinate, and then those pixels overflow and a vertical slice two pixels large appears to the right side of the cursor window
10:35 jock: any help is appreciated on how to solve this little problem
12:45 glennk: jock, does the hardware support arbitrary stride for the cursor plane, and can the plane be arbitrary 32 bit aligned address? if so, one possibility is to double the stride and fill with zero, then clamp the horizontal coordinate inside the screen and adjust the plane base address by the offset
12:49 jock: glennk: the cursor plane does not support arbitrary stride, about the alignment the datasheet does not talk about
12:54 glennk: second option, create a temp image and copy the cursor image into that, but clipped by the offset
12:54 jock: I think I understand what you say: I may always use a 128x128 plane cursor, center the cursor in the plane and then adjust all the coordinates
12:57 glennk: well, say for a 32x32 logical cursor, the temp image is then also 32x32 but has a clipped cursor image in it, offset by the overlap with the left screen edge
12:59 jock: ah ok, I understand the second option, but this way I need to recreate the cursor image on every redraw when the cursor is clipping
13:04 jock: I'm afraid that the second solution would be a bit complicated due to DMA and whatever. The hardware has a register which can be programmed with a 32 bit memory address where the cursor data resides, then the hardware does all the format conversione by itself. The whole plane update thing happens inside a spinlock, something I would not like to make heavier with data processing
13:39 jock: I'm not totally sure the cursor update also should fit in the atomic_update function: it is called on each cursor movement and each time it updates all the affected plane registers instead of just setting obe register for the cursor x/y position
14:02 glennk: i think thats generally the intention with atomic to have it all update in one go - there's also an atomic_async_update which i think is used by legacy cursor?
15:45 jock: looking in the rockchip drm code the async update is calling atomic_update(), plus some boilerplate code
16:23 DrNick: hardware cursor support that can't clip properly seems kind of useless
17:15 jock: well, it clips properly at bottom and right edges, but on the left side, when the x coordinate is negative, it overflows. This problem needs some more investigation
17:16 imirkin: jock: i think that's common
17:16 imirkin: iirc cursor coords can't be negative
17:17 imirkin: or put another way, when they are, it's ok to just not show the cursor
17:21 jock: I guess so, the hardware cursor register for the x and y positions does not accept signed values, at least the datasheet does not specify
17:40 jock: drawing selection rectangles on the xfce desktop, the cursor seems off by a couple of pixels in each direction. I need to compare with a software cursor implementation
17:40 jock: weston looks ok although
17:50 jock: ok, looks like that software and hardware cursors match with the x and y position and also hotspots are the same.
18:41 karolherbst: jekstrand: atm I am wondering if I should look into images or ffma vs fmad next
18:41 karolherbst: in regards to ffma a couple of things changed so I need to rethink my approach there
18:41 karolherbst: any preferences on images vs ffma?
18:47 karolherbst: but I think you already looked into it for clover, didn't you?
19:59 DrNick: cursor coordinates can be negative, the hotspot for the cursor doesn't have to be the upper left pixel, and if you move the hotspot to the leftmost or topmost pixel of the screen, part of the cursor image will be offscreen
20:23 jock: I understand, but that's the issue. When the cursor goes offscreen, the cursor image is wrapped to the right side of the plane. I think that's because the hardware cursor register does not allow signed values but, for example, if I assign the cursor plane to a generic overlay plane this does not happen
20:23 imirkin: DrNick: are you sure that cursor coords can be negative? this is supported by some/all hw?
20:24 jock: of course when I say that the cursor image is wrapped, I mean it is wrapped to the other side of the cursor plane, which is 64x64 pixels.
20:24 DrNick: imirkin: yeah, I fixed a radeon kms bug years ago because it had an off-by-one error when the cursor position went negative
20:24 imirkin: i definitely know that 0 is legal
20:24 imirkin: maybe the situation just never happens in practice in X, dunno
20:26 jock: The rockchip datasheet also mention that the cursor plane can go offscreen on the right and bottom edges, and actually if the cursor goes offscreen at the right or bottom edge it behaves fine
20:26 jekstrand: karolherbst: I got images mostly working in iris. It's all in a branch somewhere.
20:26 jekstrand: karolherbst: I never got 3D working though
20:27 karolherbst: I see
20:41 airlied: sounds like image next then :-)
20:41 karolherbst: yeah
20:42 karolherbst: I think I just need access to r600 hw to verify stuff doesn't break
20:42 karolherbst: somebody said that CL images are busted on radeonsi anyway, no?
20:42 karolherbst: and I think to remember that jekstrand was reworking stuff quite heavily
20:46 airlied: I doubt keeping r600 working is important, I'm not sure r600 even works
20:46 airlied: like I could plug in an evergreen and check I suppose
20:46 airlied: radeonsi never worked
20:52 karolherbst: I think EdB_ mentioned that it kind of works
20:54 karolherbst: airlied: issues like this (https://gitlab.freedesktop.org/mesa/mesa/-/issues/3494) make me think that we might want to mark static llvm/clang as totally unsupported and _all_ issues will be closed as won't fix if static libs are used :p
20:54 karolherbst: doesn't seem to be worth the trouble to support broken distributions :p
20:55 karolherbst: especially this shared llvm but static clang nonsense
21:03 FLHerne: +1
21:04 FLHerne: At least they haven't started patching mesa to outright break it yet
21:06 FLHerne: With kdev-python I had "if ( PYTHONINTERP_FOUND AND PYTHON_VERSION_STRING VERSION_GREATER "3.4.2" )" -> Ubuntu packagers: "oh, but we have 3.4.0" -> sed s/\.2// -> unhappy users
21:07 FLHerne: I mean, it literally *did not work at all* with 3.4.0, so there's no way they even tried to test it
21:10 kisak: karolherbst: I'm pondering if that PPA user will notice that I fast tracked the polly build change into my build and they just need to pull updates. It's hard to call it an urgent issue when it's been broken in the wild for 5 months
21:11 karolherbst: kisak: my comment on the entire situation is: if you use static libs, it's your problem
21:12 kisak: oh, wrong date, not 5 months
21:13 dcbaker[m]: karolherbst: isn't shared clang relatively new?
21:13 karolherbst: dcbaker[m]: why would it be?
21:14 karolherbst: I think this single component library is quite new, but you could have multi component shared lib builds for a long time
21:14 dcbaker[m]: I seem to remember that libclang used to be static only
21:14 karolherbst: oh well, if that's the case, nice of clang to finally get fixed :p
21:14 dcbaker[m]: Llvm has been both, but I thought clang was static only
21:14 dcbaker[m]: I could be wrong though
21:15 karolherbst: well, all I can see is that llvm/clang packaging makes it harder for everybody and it's the only library which constantly is causing issues
21:16 dcbaker[m]: No arguments there
21:16 dcbaker[m]: If they would just ship pkg-config that would make my life easier :)
21:16 karolherbst: no kidding
21:16 karolherbst: at least there is llvm-config
21:16 karolherbst: but for clang you don't have anything afaik
21:18 dcbaker[m]: Llvm-config is a joke. It basically only works correctly in two configurations with various levels of brokenness on other OSes
21:18 karolherbst: sure
21:18 dcbaker[m]: And configs
21:21 hanetzer: blarg
21:21 bnieuwenhuizen: dcbaker[m]: given that tjaalton messaged that is getting harder to get 20.2 in ubuntu 20.10 do we have an outlook on a final release?
21:22 dcbaker[m]: Tomorrow. I got all the ci results Saturday, just need to cut the release
21:22 bnieuwenhuizen: ok, thanks!
21:34 airlied: karolherbst: yeah clang only grew dynamic biglib support recentlyh
21:34 airlied: so not all distros have turned it on yet
21:36 karolherbst: airlied: I mean.. sure, but what was the issue before with the multiple component stuff, long loading times or inter shared lib call overhead and stuff like that?
21:38 hanetzer: I assume that dri-devel folks generally have gpus of varying sorts. Does anyone here happen to have an rx 5700 xt, and perhaps one of the ryzen am4 motherboards, which does properly provide output via the gpu in a pre-os environment?
21:38 hanetzer: eg, POST/BIOS interface/bootloaders
21:39 hanetzer: dcbaker[m]: its herra broke on a double-cross system
21:43 dcbaker[m]: hanetzer: double-cross?
21:46 hanetzer: yeah. at least on gentoo. Not quite a canadian cross but still a bit more exotic than x86_64-pc-linux-gnu to aarch64-linux-gnu; ${arch1}-${libc1} to ${arch2}-${libc2}
21:49 dcbaker[m]: I'll try in the morning before I release
21:49 airlied: karolherbst: well I think we can't disable static clang prior to maybe llvm 10
21:49 dcbaker[m]: I run Gentoo and have a cross aarch64 Toolchain
21:49 airlied: but we should definitely get distros using llvm10 and later to package clang in it's single shared form
21:50 airlied: and maybe mesa should explode properly to motivate tht
21:50 karolherbst: I was thinking about writing an MR to enforce it
21:50 karolherbst: and in the static lib case print a warning saying "all bug are on you"
21:50 karolherbst: *bugs
21:50 airlied: yeah just make sure it's for llvm10 and above
21:51 airlied: though it might make CI tricky, since I've no idea how the llvm packages we use are configured
21:51 karolherbst: or "all build system bugs against static llvm/clang _will_ be closed as 'not our bug'"
21:51 karolherbst: airlied: debian is static
21:52 karolherbst: but yeah.. not sure what we actually use, but I think we just use the debian packages
21:54 airlied: we use some packages from debian and some from llvm I think
21:54 karolherbst: airlied: fun fact: even llvms official deb files do static shit ...
21:54 karolherbst: just libclang-12.so is shared
21:54 airlied: yeah that lib is useless
21:55 karolherbst: I'd just burn it down somehow
21:55 airlied: that's some interface for ast only stuff
21:55 airlied: like text editors
21:55 airlied: it's no use for compiling
21:55 airlied: that's what libclang-cpp-12.so should encapsulate
21:55 karolherbst: maybe add a compiler flag: "-DUse_unsporrted_static_llvm_clang"
21:55 karolherbst: so people having to turn it on, like debian, know they won't get any support from us
21:56 karolherbst: they can just fix the issues themselves for all I care :p
21:56 airlied: yeah it's just how to get that into CI :-P
21:57 karolherbst: yeah...
21:59 karolherbst: ohh wait...
22:03 karolherbst: airlied: ohh, I was actually wrong
22:03 karolherbst: they have a libclang-cpp package
22:03 karolherbst: and we already use it since llvm-9
22:03 karolherbst: in CI
22:04 hanetzer:still hates_the_underscore_flag_denotation
22:04 karolherbst: airlied: so I guess I just make the build hard file and if nobody complains we just merge it :p
22:05 karolherbst: I think llvm-9 had some funky issues though? But that seems to be fine with our CI
22:05 karolherbst: uhm...
22:05 karolherbst: libclang-cpp9 I mean
22:09 karolherbst: ohh, it wasn't. It was just somebody mixing system + local libraries I think
22:09 karolherbst: ohh, BUILD_SHARED_LIBS=YES was broken.. oh well
22:16 dcbaker[m]: hanetzer: I think upstream meson is planning to make - and _ equivalent in option names
22:16 hanetzer: I don't like that.
22:16 hanetzer: autotools automagic creeping in.
22:21 dcbaker[m]: Well, they wanted to remove - but that would break a lot if projects. I'm not sold on it myself, but we've mostly used - in Mesa
22:26 hanetzer: personal thought: should always be -, because <shift>- for_each_flag_like_this_is_ass_to_type
22:27 dcbaker[m]: That's my opinion too