01:41 icecream95: Is there any reason that buffer_target_to_bind_flags returns PIPE_BIND_RENDER_TARGET for GL_PIXEL_{,UN}PACK_BUFFER?
03:27 pichika: Hello
06:27 hakzsam: imirkin: yeah, cupti is the thing I used to RE perf counters. I think this repo is a bit outdated though :)
08:01 MrCooper: ajax: the image sizes shouldn't matter that much, if the runners didn't keep re-downloading them over and over... case in point, the Windows x64_build image is way bigger than the Linux ones, but it's not in the top 6 graph on grafana (though it is #7 :)
08:02 MrCooper: ajax: also, splitting images could be counter-productive, since some of the data would be duplicated
10:16 bbrezillon: karolherbst: I see you're setting spirv_options.constant_as_global to true in clover, but when we do that we have a crash when declaring local const arrays (something like http://code.bulix.org/cnbn4q-1275854)
10:16 bbrezillon: do you have the same issue?
10:17 karolherbst: yes
10:17 karolherbst: and I don't have a good solution yet
10:17 bbrezillon: me neither :-(
10:17 karolherbst: I think ultimately I only want to convert constant kernel args to global and clean up the kernel from there
10:17 karolherbst: but that's more work
10:17 karolherbst: the painful part is just how constants are declared inside spirv
10:18 bbrezillon: I have a patch turning UniformConstant with initializer to UBOs, but that doesn't if we add pointer pointing to this const array
10:18 karolherbst: yeah...
10:18 karolherbst: but I think this is the right approach
10:18 karolherbst: normal constats will stay constants and indirectly accessed arrays will be stored in ubos
10:18 karolherbst: on hardware you hardly can do anything else anyway
10:19 karolherbst: what's troubling is just kernel args
10:19 karolherbst: I would just treat constant args as ubos, but... you can't do this if you want to conform to the spec
10:19 karolherbst: it's just annoying
10:20 karolherbst: even nvidia turns those into global loads
10:20 karolherbst: just with different caching
10:20 karolherbst: but I also saw them changing this behaviour sometimes
10:21 HdkR: That different caching is good stuff :)
10:21 karolherbst: bbrezillon: what's the most annoying issue and you can more or less ignore this in CL 1.2 without ext: SVM
10:22 karolherbst: so you can bind an SVM pointer to a constant arg
10:22 karolherbst: and then you are screweed
10:22 bbrezillon: :'-(
10:22 karolherbst: yep
10:22 karolherbst: my thoughts exactly
10:22 karolherbst: there is an arm SVM extension valid for 1.2
10:22 karolherbst: so... it's not just a 2.0 issue
10:23 karolherbst: essentially just the SVM backport to 1.2
10:24 karolherbst: bbrezillon: I kind of feel we need to implement generic pointers already with in kernel address range translation
10:25 karolherbst: then this problem would essentially just go away
10:25 karolherbst: still needs some kernel rewrites, but.. well
10:25 karolherbst: but then it's manageable
10:27 bbrezillon: karolherbst: you lost me :-) (I'm still new to the OpenCL world and don't know all the concepts yet)
10:27 karolherbst: SVM: shared virtual memory, so you have one VM across GPU and CPU
10:28 bbrezillon: yep, that one I had it :)
10:28 karolherbst: and you can pass in malloced or SVMAlloced memory directly into the kernel
10:28 karolherbst: generic pointers: pointers without address type declaration
10:28 bbrezillon: ok
10:28 karolherbst: int*a instead of global int *a
10:28 karolherbst: only valid for global, local and ... the other one
10:28 karolherbst: not valid for constant though
10:29 karolherbst: helps implementing generic functions without having to add duplicates for every address type
10:29 bbrezillon: and address range translation?
10:29 karolherbst: you convert a pointer to another one
10:29 karolherbst: eg a local memory pointer to global
10:29 bbrezillon: so global to local for instance
10:29 bbrezillon: ok
10:29 karolherbst: well
10:29 karolherbst: back to local is difficult and I would ignore this
10:30 karolherbst: CL doesn't even allow this in a serious manner
10:30 karolherbst: you can always cast.. but uff
10:30 karolherbst: the best idea here is to just case x to global in case you have conditional code
10:30 karolherbst: and always inline such helper functions to optimize translation away
10:31 karolherbst: or duplicate the functions or whatever
10:31 mlankhorst_: mdnavare: that's what tooling is for :)
10:31 bbrezillon: but that wouldn't solve the constant issue if you say generic pointer only works for the global and local address space :)
10:31 karolherbst: well..
10:32 karolherbst: of course we can also convert an ubo address into a global memory pointer
10:32 karolherbst: just the spec doesn't allow it
10:32 mlankhorst_: mdnavare: update drm-rerere to latest first, then use dim create-branch
10:32 karolherbst: but hw? sure
10:32 karolherbst: no issue
10:33 karolherbst: on nvidia you even have to do it as you only have 6 const buffers
10:33 karolherbst: well 8 but we need two for other things
10:33 karolherbst: so...
10:36 bbrezillon: ubo -> global means copying the UBO values to the global, right?
10:36 karolherbst: no
10:36 karolherbst: it's already there
10:36 karolherbst: at least for us
10:37 karolherbst: but accessing an ubo through special means just goes through an on chip cache
10:37 karolherbst: but it's always in VRAM
10:37 karolherbst: so we can just convert an ubo index into a base address of that in VRAM
10:37 karolherbst: other hardware might be different there
10:38 karolherbst: or well.. system memory, I guess that would work too
11:50 pcercuei: Trying to implement a plane that supports scaling
11:50 pcercuei: drm_atomic_helper_check_plane_state() doesn't modify plane->src / plane->dst to adjust them to the scaling factor?
12:02 pq: pcercuei, um, what scaling factor? Doesn't src/dst define the scaling factor?
12:05 pcercuei: it does
12:06 pcercuei: if I want to scale from 239 pixels to 320, I'd get a 4:3 scaling factor, since my hardware can only do X:Y scaling with X/Y < 32
12:06 pcercuei: so the source width should be adjusted from 239 to 240
12:06 pq: I don't think you can change source width at all.
12:06 pq: Userspace wouldn't expect to get something else than what it asked for.
12:07 pcercuei: It worked fine with fbdev
12:08 pq: are you sure? Can you spot the missing/gaining one pixel?
12:09 pq: what if adjusting the source width makes you go out of source FB bounds?
12:09 pcercuei: SDL will happily paint the extra line black
12:10 pq: huh?
12:11 pcercuei: Well, atomic_check will be called before a fb object is created, right? Then the size will already be modified
12:11 pq: how can SDL paint the 240th pixel if there is FB for just 239 pixels?
12:11 pcercuei: SDL requests 239 pixels width, it gets 240, and is happy with that
12:11 daniels: pcercuei: no, the FB has to be created first, because you have to pass the FB to atomic_check ...
12:12 pq: pcercuei, no, I'm quite sure SDL does not work like that. The FB is part of the atomic state when you check it, like daniels says.
12:12 daniels: you create the FB with its full w/h, you apply the FB (with src w/h) to a plane (with dst w/h), and you test that
12:12 daniels: those stages are completely separate
12:12 pcercuei: pq: oh, I guess it didn't work for thousands of users for the last 6 years then
12:12 daniels: this is literally how KMS works
12:12 daniels: KMS can't make framebuffers bigger or smaller
12:13 pq: pcercuei, sounds like they are not getting what they asked for, but no-one noticed.
12:13 pcercuei: pq: or maybe it works and you're wrong?
12:13 pcercuei: I wrote that myself, I know how it works
12:13 pcercuei: a fbdev driver's check_var callback is free to modify what the userspace requested
12:14 pq: there may be miscommunication here
12:14 pcercuei: and the userspace has to be fine with that
12:14 daniels: that's something fbdev can do
12:14 daniels: it's not something KMS can do
12:14 pq: I'm not talking about fbdev, fbdev buffers are immutable.
12:15 pq: Userspace does not allocate fbdev buffers, it just uses that the kernel happens to hand over. With KMS, userspace actually allocated its own buffers with its own sizes.
12:16 pcercuei: without asking the kernel if the buffer it allocates is actually usable?
12:16 pq: So if userspace allocates a buffer of 239 wide, the 240th pixel does not exist as long as userspace is concerned, so it cannot paint it either. The bytes for the 240th pixel might exist in the padding, but padding must not contribute to the image.
12:16 pq: pcercuei, yes.
12:17 pq: pcercuei, atomic check is for checking if the buffer is usable.
12:18 pq: pcercuei, when userspace allocates dumb buffers, the only thing the kernel can decide about dimensions is stride. Or it can just fail the whole allocation.
12:18 pcercuei: well this is stupid. I understand it's done that way, but that means now I'm stuck between a rock and a hard place
12:18 pcercuei: can't upstream the fbdev driver, can't update to KMS.
12:18 pq: pcercuei, what's the problem?
12:19 pcercuei: my scaler supports X:Y scaling with 1 < X/Y <= 32
12:19 pq: ok
12:19 pcercuei: so I can't scale from 239 to 320 without adjusting the source width
12:19 pq: Do you *have to* support scaling factors that your hardware cannot achieve?
12:20 pcercuei: for legacy reasons, yes. Don't want to break all the apps made so far
12:20 pq: You actually have KMS apps (not fbdev) that allocate 239 wide buffer and expect such scaling to work?
12:21 pcercuei: SDL apps. So they use fbdev today, they may use KMS tomorrow
12:22 pq: I don't think fbdev using apps can be a problem, since userspace does not control the buffer size AFAIK. So I'm wondering how they can even pick 239 to begin with.
12:23 pcercuei: there's a ioctl to request a video mode
12:23 pq: yeah, video mode, not buffer size, right?
12:24 pcercuei: the buffer size is calculated from the video mode
12:25 pq: wait, how does scaling even happen with fbdev?
12:27 pq: pcercuei, sounds like it might be good to fully explain your hardware limitations in an email to dri-devel@ and ask how you can fulfill the requirements your existing userspace has.
12:27 pcercuei: userspace would request a mode via check_var / set_par ioctls, e.g. 240x160. The fbdev driver would compute the scaling factors and the coefficient tables to have the 240x160 framebuffer shown on the 320x240 screen
12:28 pq: ok, so that's automatic scaling for a panel that cannot scale itself or cannot accept anything but a fixed mode?
12:28 pcercuei: scaling worked by having the driver accept all mode requests, tweaking a bit the W/H size if needed to get valid scaling coefficients
12:29 pcercuei: yes, exactly
12:29 pq: and you have userspace that asks for a 239-mode instead of a 240-mode?
12:30 pcercuei: not 239 in particular, but yes, modes that give problematic scaling values
12:30 pq: so how did it actually work with fbdev? Does the old driver force the buffer allocation to be bigger than the requested mode?
12:31 pq: and then you scale up an area of the buffer that is larger than what userspace thinks it is?
12:32 pq: that is, you show pixels the userspace is not aware of?
12:33 pcercuei: On fbdev the buffer is not created when the mode is set, but when the driver probes. A "big enough" framebuffer is created
12:33 daniels: yeah, in fbdev the user requests a mode, the driver does _something_, then the user reads back whatever mode the driver has actually set and does something with that
12:33 pcercuei: yes this ^
12:33 danvet: so maybe a few things
12:34 danvet: current fbdev emulation in kms doesn't support modesets
12:34 danvet: so if you want that, it's going to be tough
12:34 danvet: as in, you'll have to type code
12:34 danvet: what we could do there is that in the emulation check_var we go through the mode list
12:34 danvet: and pick whatever is "closest"
12:34 danvet: now for kms itself, what we do for panel drivers which a) want a fixed mode b) have a panel fitter
12:35 danvet: is: you generate all the modes you support
12:35 danvet: that way userspace knows what's possible
12:35 danvet: because yes for plane scaling it can randomly fail and atm there's no hints to userspace
12:35 danvet: but for entire output scaling we do have solids hints, its the mode list
12:36 danvet: pcercuei, ^^ that good enough for your use-case, or did I misunderstand your use-case?
12:36 pcercuei: up/down scaling everything from 4x4 to 4096x4096, with X:Y scaling factors, to the size of the screen
12:36 pcercuei: that's just too many combinations
12:36 danvet: if you want example, edp on any i915 machine: everything except the native mode is fake stuff we add
12:36 danvet: pcercuei, pick all the popular ones at least
12:37 danvet: here on my laptop we add like 40 or so fake modes
12:37 danvet: and that only goes up to 1080p
12:38 pcercuei: Note that right now the algorithm increases the source width/height until a valid scaling factor is found. I could make it *decrease* the width/height and it'd work with KMS, but then I'd lose entires lines and rows of pixel data
12:39 pq: yeah, not good
12:39 pq: I suppose you don't have to add all possible combinations. Userspace can still attempt to use unlisted sizes through plane src/dst coordinates, and you can reject bad ones in atomic check.
12:39 pcercuei: well, I don't know what is "popular" here... the hardware mainly runs emulators, so you get all the funky resolutions the SNES, PSX etc. request
12:39 danvet: pq, yeah atomic still allows you to use unlisted stuff
12:40 danvet: pcercuei, ah i vs p and different clocks is all on top of this
12:40 pq: video modes are a primary plane thing, and a buffer of the size of the video mode really should work. But userspace is not limited to that, the API allows attempting scaling explicitly via src/dst rectangles.
12:40 pq: and userspace can also invent video modes out of thin air
12:42 pq: pcercuei, what I believe you are allowed to do is, when you scale up from userspace video mode to the panel mode, you can leave some panel pixels unused.
12:42 pcercuei: yes, but it doesn't work that way;
12:42 pq: why?
12:43 pq: your CRTC does not have a concept of background?
12:43 pcercuei: if I get a width of 239 and my panel is 320, then how I adjust the panel's position and size doesn't matter
12:44 pcercuei: you'll never find a valid scaling factor to scale from 239
12:44 pq: ok
12:44 danvet: the other question I have ... how much userspace asks for 239 wide buffers?
12:45 danvet: as in, how much is this a problem in practice
12:45 pcercuei: few apps, but these apps are used a lot
12:46 pq: then your fbdev using userspace will remain stuck with fbdev, until it gets a KMS implementation that uses KMS correctly, as in, e.g. trying only the advertised video modes.
12:46 danvet: or at least try a few things
12:46 danvet: I mean 239 doesn't work on a hole lot
12:47 danvet: much hw with 8 pixel alignment requirements
12:47 danvet: because that's what vga had
12:47 danvet: pcercuei, do you have a link somewhere for that 239 wide mode?
12:48 danvet: for snes/psX/whatever
12:49 pcercuei: I took 239 as an example, you'd probably never see this particular value
12:49 pcercuei: pcercuei: not 239 in particular, but yes, modes that give problematic scaling values
12:50 pq: SDL could as well round up the app-requested mode to the nearest supported mode on KMS. On fbdev that was done by the kernel. I mean, when you write userspace for KMS, you don't expect KMS to eat everything you can imagine.
12:51 pq: quite the contrary, really
12:51 pcercuei: These userspace apps existed long before KMS, though
12:51 pq: sure - they won't use KMS then
12:52 danvet: pcercuei, fbdev emulation can do this transparently
12:52 danvet: iff someone would bother to write modeset code for it
12:52 danvet: atm it just corrects you back to the resolution it picked
12:52 pcercuei: awww really?
12:53 danvet: so your use case already "works"
12:53 pcercuei: Now I get to choose between adding modeset to fbdev emulation, or adding KMS support to old SDL1
12:53 pcercuei: Talking about working on stuff nobody cares anymore... lol
12:53 pq: pcercuei, why would you ever add KMS support to old SDL1?
12:53 danvet: hm actually not sure
12:54 danvet: I think it just lets it slide through
12:54 danvet: with no scaling
12:54 pcercuei: pq: because SDL1 apps requests all kinds of fancy resolutions, and the fbdev emulation has no modeset support
12:55 pq: pcercuei, is SDL1 expecting the fbdev modeset succeeds without checking what it actually got?
12:55 danvet: pcercuei, improving the fbdev emulation is probably best I'd say
12:55 pcercuei: if I add all combinations of modes that my scaler supports, I get to about 8k modes :)
12:55 pcercuei: 1k per pixel format
12:55 danvet: modes aren't per pixel format
12:55 pcercuei: ok, then 1k
12:55 pq: you don't have to add so many modes
12:56 danvet: yeah I guess not many who want something massively distorted
12:56 pcercuei: pq: no, SDL1 would check what it got. The app would run fine. Just not scaled
12:56 danvet: I still think that listening a bunch of common ones (like we do)
12:57 danvet: and teaching fbdev emulation to pick the closest one (rounding up I guess) should pretty much get you there
12:58 pq: pcercuei, since you have your few userspace programs you care about, add the modes they need, and get them working through the fbdev emulation. That would seem like the best to me.
12:58 pcercuei: but fbdev emulation has no modeset?
12:59 pq: what danvet said
13:00 pcercuei: I can't even add "common modes"
13:00 pcercuei: because "common modes" depend on the screen's resolution
13:00 pq: If you say so. *shrug*
13:00 pcercuei: these modes wouldn't be the same for a 320x240 panel, or a 1080p panel
13:01 ccr: iirc there exist SDL2 wrappers for SDL1, not sure if any of them are ABI compatible tho .. or how compatible they can be. https://github.com/MrAlert/sdlcl for example.
13:02 pcercuei: ccr: yes, I've been testing with the sdl1-compat lib too
13:02 pcercuei: problem is, SDL2's KMS backend sucks
13:02 pcercuei: it requires a GPU, only works with EGL
13:03 pcercuei: I have a proof-of-concept that makes it work with regular GEM buffers, so that software rendering is possible
13:03 ccr: ok
13:03 pcercuei: but... performance is half of SDL1 (didn't profile it yet, TODO), and I broke GL support
13:03 pcercuei: So not really in an upstream-ready state
13:07 danvet: pcercuei, you can be dumb and just add them all
13:07 danvet: and then let ->mode_valid filter them out
13:08 pcercuei: alright
13:09 pcercuei: By "fbdev does not support modeset", do you mean that I cannot set video modes from a fbdev-using app?
13:09 pcercuei: Just want to make sure I understood properly.
13:11 rellla: anholt: i try to use your gpu-trace-perf and run into https://pastebin.com/raw/SbG1wZSP
13:11 rellla: it seems, that gpu-trace-perf can't find apitrace?
13:12 rellla: apitrace is in PATH and working standalone
13:12 rellla: any hints?
13:14 danvet: jstultz, did you see my nag on "drm: kirin: Add register connect helper functions in drm init"?
13:15 danvet: pcercuei, yup
13:15 danvet: you also get the modes we pick at boot-up
13:15 pcercuei: ok
13:15 danvet: I was kinda assuming you've noticed this already
13:15 danvet: or is this here a 100% conjecture discussion?
13:23 pcercuei: Well I didn't notice it yet, because right now I'm still writing the scaler plane
13:23 pcercuei: so apps requesting a mode change would always get the screen resolution, since it's the only one available
13:23 vivijim: airlied: danvet: 3 first vfio patches on this series https://patchwork.freedesktop.org/series/72038/ have landed on Linus' master... gvt guys wants a backmerge so we can send the rest of the patches yet for this 5.7... possible? should we wait to move things from drm-next to drm-fixes?
13:25 pcercuei: danvet: you asked for it, an example of upscale that wouldn't work: Super Nintendo NTSC resolution (256x224), upscaling to 720p (1280x720)
13:25 pcercuei: it works for the width (5:1), but for the height you get a 45:14 scaling factor
13:26 danvet: vivijim, too late, 5.7 closed in -rc6
13:26 pcercuei: what my fbdev driver would do, is change the requested 256x224 to 256x240, which then gives you a vertical scaling factor of 16:3
13:26 danvet: imo
13:27 danvet: if you have this kind of stuff you need a topic branch
13:27 danvet: or it gets spread over multiple merge windows
13:27 danvet: in this case here it's botched up and well material for 5.8 I'd say
13:28 pcercuei: 256x224 would scale correctly to 320x240, just not to 720p. So in the predeterminated modes, I'd need one for 256x224 and one for 256x240
13:28 danvet: pcercuei, oh is your limit that X:Y both X and Y can at most be 32?
13:28 pcercuei: yes! exactly
13:29 danvet: yeah you wrote something like X/Y <= 32
13:29 danvet: which I interpreted to mean something else
13:29 pcercuei: oooh, sorry about that
13:29 vivijim: danvet: yeap... I was looking more carefully the patches specially the last one... I agree that it is too late
13:29 danvet: well random hw restrictions are random
13:29 danvet: vivijim, should have done a topic branch, well requested one from vfio
13:37 vivijim: yeap topic branch would be indeed good on this case
13:59 daniels: karolherbst: so does your nouveau branch work on something like llvmpipe? wondering if I can help by testing your MR as-is rather than going back and forth from two different trees ... but I don't have any nv
14:00 karolherbst: daniels: it should afaik
14:00 karolherbst: airlied did most of the llvmpipe compute work for this
14:03 karolherbst: it might be that I broke something, but I highly doubt it... I think there are some regressions or minor bugs I still have local fixes for
14:03 karolherbst: eg stuff like this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4068
14:03 daniels: ok, let me try to find out
14:03 daniels: if there are any other MRs I should try to pull in as well to test, please let me know
14:04 karolherbst: I have a bunch of fixes on my clover_support_hmm_wip, but I am also sure some of it breaks stuff
14:06 karolherbst: anyway, I'd rather know which issues you run into based on master anyway, so I know what to focus on next
14:09 karolherbst: daniels: you might also need something like this: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/9912b03aff94991cfed9694c03a91555158b7fa5 at least the nir bits
14:09 karolherbst: fixes some ptr derefing
14:09 karolherbst: but.. well
14:09 karolherbst: it breaks gl
14:13 daniels: heh
16:10 jvesely: MrCooper: not sure what your point is beyond crapping on a distro. any problems with BUILD_SHARED_LIBS are bugs that are fixed. Using single library has beenfits in hiding few symbols and speeding up loading time, which really only matter during testing.
16:12 MrCooper: jvesely: normal users care about loading time as well, not to mention it can make piglit runs take orders of magnitude longer
16:14 jvesely: piglit is a testing run and hardly something 'normal users' do. applications that load LLVM once don't need to care if it takes 10ms or 100ms to start
16:15 karolherbst: building one lib has perf benefits though
16:15 jvesely: I agree there is no benefits to BUILD_SHARED_LIBS for those who do not build LLVM regularly, but it's hardly 'screwing their users'
16:16 karolherbst: besides loading times
16:16 karolherbst: anyway, gentoo moved to BUILD_SHARED_LIBS=OFF as well so it doesn't really matter anyway
16:17 MrCooper: yeah, glad they finally fixed that
16:17 jvesely: unless you benchmarked it, it's potential benefits. anyway distros should definitely stick to a single library as advised by upstream
16:17 MrCooper: sounds like we're in violent agreement then :)
16:18 jvesely: I've been testing full OCL piglit runs for years and the setup is faster with BUILD_SHARED_LIBS
16:18 karolherbst: having fewer so files has perf benefits, that's more or less a stated fact, calls between so files are more expensive than calls within one, that's just how it is
16:18 jvesely: at least for llvm-git, the speed up in piglit run time does not offset 10mins+ linking time, and debug builds are slower anyway
16:19 MrCooper: that's relatively few & long running tests; try a GL suite (without --process-isolation false)
16:19 karolherbst: anyway, benchmark based on debug builds are worthless anyway
16:19 karolherbst: (and we can also include LTO in this discussion, etc...)
16:20 karolherbst: and in the end more practical differences matter for users
16:20 karolherbst: no +1% perf here and there
16:20 jvesely: I'm not saying that using GOT/PLT trampoline is faster. I'm saying the difference is not measurable in normal applications, so the benefit is 'potantial' until you find and measure a specific worklaod
16:21 karolherbst: always depends on the scale, but yes
16:22 jvesely: OCL benchmark runs are OK ebcause the kernels are built separately (out of the timed section)
16:22 MrCooper: jvesely: FWIW, my monolithic LLVM libs are 200-odd MB, link in seconds, and work fine for my debugging most of the time
16:23 jvesely: anyway I'm running benchmarks, just daily test runs to catch clover regressions; latest mesa + llvm-{5,6,7,8,9,10,git} on turks can carrizo
16:24 karolherbst: I'd argue that cl stuff in piglit isn't good enough to catch regressions though
16:24 karolherbst: but then if you start digging into the official CTS it's .. well
16:24 karolherbst: a lot of work
16:24 jvesely: it's good enough to catch basic functinality and all libCL functions are tested
16:24 karolherbst: it's not
16:24 karolherbst: I know a lot of API calls which are broken
16:25 karolherbst: even the compile functions are not correctly implemented
16:25 karolherbst: no callback handling eg
16:25 jvesely: I'm not talking about API calls, I'm talking about CLC functions
16:25 karolherbst: so the cTS hangs forever on those
16:25 karolherbst: ahh yeah.. well
16:25 anholt: rellla: hmm, failed even before getting output.status.success() check, makes me wonder if your apitrace-before.sh is findable and executable. (I found my scripts needed a #!/bin/sh at the top that was missing)
16:25 karolherbst: right
16:25 anholt: thanks for giving the tool a shot, would love to polish this stuff.
16:26 jvesely: basic kernel build+invocation + exposed CLC functions work
16:26 karolherbst: jvesely: was libcl even verified to pass the CTS in the lib functions?
16:26 karolherbst: that would be interesting to know
16:26 jvesely: yes
16:26 jvesely: it passes all integer and FP CTS tests on my carrizo/iceland setup
16:26 karolherbst: okay.. I guess I should apply airlied stuff on my tree locally and see how that goes on nouveau
16:27 jvesely: turks passes all scalar tests except divide and half_logX
16:28 jvesely: it used to pass vector versions as well, but that regressed around llvm-8 and I didn't have time to fix it
16:29 jvesely: I know awatry, reported some failures on earlier GCN hw, but I don't have HW to look into it (iirc it was only one function)
16:29 karolherbst: okay.. well, I will see how the generic implementation will work out soon enough anywa
16:29 karolherbst: y
16:32 jvesely: despite what was said about clover it works mostly OK if you don't divert from build kernel+invoke kernel basics. most of the effort was to get the CL kernels to actually return correct numbers rather than fixing more rarely used features.
16:38 karolherbst: I wished we would have a better solution for CLANG_RESOURCE_DIR
16:38 karolherbst: oh well
16:40 jvesely: anyway the daily piglit results are at https://jvesely.github.io/piglit/gcn-latest-3/problems.html
16:41 jvesely: i'm also semi regularly building libclc with some custom patches: https://ci.appveyor.com/project/jvesely/llvm-project-libclc/history
16:41 Lyude: seanpaul: btw - I sent out the respin of the ACT fixes yesterday-if you could give the OK for https://patchwork.freedesktop.org/patch/360351/?series=75482&rev=2
16:45 karolherbst: jvesely: cool! I wished we could add some CI jobs based on airlie patches + llvmpipe clover to verify this without having to rely on special hardware
16:46 karolherbst: but I guess GPU specific regressions are still possible
16:46 jvesely: I had a similar testing setup for raven, until one of MrCooper's kernel patches broke clover on raven and I couldn't even get a reply for months
16:46 karolherbst: but outside of the scope of non r600 drivers anyway
16:48 MrCooper: jvesely: remind me which patch that was?
16:48 jvesely: I had plans to add LLVM based clover support to llvmpipe, but between moving and working on my thesis I can barely keep the existing test setup running.
16:49 jvesely: MrCooper: https://bugs.freedesktop.org/show_bug.cgi?id=109649
16:50 jvesely: to be fair, I don't think that patch is wrong, it just exposed bugs elsewhere
16:53 MrCooper: I'm not Christian König BTW :)
16:54 jvesely: oh, wrong person. sorry about that
16:55 MrCooper: no worries
17:00 anholt: rellla: pushed 1.2.1 which should help your debug.
17:33 rellla: +anholt: thanks, i'll check it tomorrow
17:43 shadeslayer: Hi! Could someone assign MR 4435 to margebot?
17:48 anarsoul: shadeslayer: ping someone responsible for CI?
17:48 anarsoul: daniels: ^^
17:51 karolherbst: anybody up for reviewing some clover SVM patches? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2076
18:02 anholt: shadeslayer: done
18:02 anholt: anarsoul: any mesa developer can, including you.
18:04 anarsoul: anholt: I thought the convention is not to merge MRs you're not familiar with
18:04 anholt: anarsoul: not sure how "someone responsible for CI" would be closer to that. the author of the mr thinks it's ready, and it's got review, so seems good to me.
18:05 anholt: I guess in that it's a CI-ish MR?
18:05 anholt: (I guess I'm just a little sensitive to people treating "CI folks" as some separate category)
18:06 anarsoul: yeah, what I meant is someone familiar with CI
18:19 sravn: pcercuei: Are you going to apply this patch: gpu/drm: ingenic: Delete an error message in ingenic_drm_probe()
18:20 shadeslayer: anholt: thanks!
18:20 sravn: pcercuei: If you do, please fix subject to drm/ingenic
18:20 pcercuei: alright
18:21 pcercuei: to drm-misc-next?
18:28 pcercuei: dim extract-tags doesn't seem able to find my 'Reviewed-by'
18:28 pcercuei: I guess it doesn't matter if there is my Signed-off-by?
18:29 jstultz: danvet: yea, I saw.. will take a look at it. it was a precursor for a patch series that was "left" to me after the trade restrictions landed, and i've not found time to get them cleaned up (unfortunately it has tons of long lines of macro equations and whitespace issues I need to carefully rework and hope I don't accidentally change). I'll try to fixup upstream and then find time to rework the series so I can submit.
18:31 danvet: jstultz, pretty sure that no matter what you want to do, this wont help
18:32 danvet: at the point you're calling drm_connector_register, they're registered already
18:32 danvet: and drm_connector_register is a no-op
18:32 danvet: incidently, calling drm_connector_register before drm_dev_register is also a no-op :-)
18:32 jstultz: danvet: i'm sure. i'll have to look at it later today.
18:33 danvet: hm
18:33 danvet: just realized that if you race a dp mst drm_connector_register against a drm_dev_register it could go wrong
18:33 danvet: Lyude, ^^
18:33 danvet: in case you run out of stuff to fix around dp mst :-)
18:37 mdnavare: danvet: I am merging a patch series that has 2 patches in drm/amd and drm/drm_dp_helper.h and rest in i915 , should I merge them all through a topic branch in drm-misc?
18:38 danvet: feels like overkill, if you can convince all maintainers to just ack it for merging through drm-misc-next
18:39 danvet: if that can't be had, ask mripard mlankhorst_ tzimmermann for topic branch and that they merge this stuff
18:47 sravn: pcercuei: drm-misc-next should be fine imo. And you have "approved" the patch so you do nto need a r-b. But you can add mine if you like.
18:48 sravn: pcercuei: For patches I apply I seldom add my r-b. When I have spent more than just average time to review I sometime do it. So for a quick (less than 5 min review) I just apply
18:48 pcercuei: alright
18:49 pcercuei: pushed
18:52 daniels: karolherbst: would you like a patch to inline opencl-c.h into the binary rather than loading it at runtime?
18:53 Cogitri: Hello. Just wanted to ask here if there's a bugreport for weird graphical glitches in XWayland since Mesa 20.x like this already: https://gitlab.alpinelinux.org/alpine/aports/issues/11367
18:53 karolherbst: daniels: I think there is an option on clang to include default headers, which would also solve this problem
18:53 karolherbst: but
18:54 Cogitri: Not really sure what to search for on Gitlab for that
18:54 karolherbst: then we still have the search paths for libclc
18:56 mdnavare: mlankhorst_: Would you be able to merge the DP PHY compliance patch series: https://patchwork.freedesktop.org/series/71121/ through a drm-misc topic branch since it has patches from drm as well as i915 so as per suggestion of danvet and j4ni merging through topic branch is better
19:00 daniels: karolherbst: yeah, we're xxd'ing that for DX12 as well ...
19:01 daniels: btw I'm still going through rebuilding everything on Linux to test your branch, I haven't forgotten
19:01 karolherbst: cool, thanks
19:02 sravn: pcercuei: thx, just catching up on a lot of patches..
20:29 imirkin: Cogitri: it's unclear what the setup for the issue is ... is it in qemu, or is it on bare metal? if on qemu, is it using virgl, and what's the host-side driver?
20:30 imirkin: (or is it using llvmpipe)
20:33 Lyude: mdnavare: hey!
20:34 Lyude: i'm here now, do you still need help with the topic branch?
20:43 Cogitri: imirkin: This is on bare metal
20:43 Cogitri: It might happen in Qemu too, dunno
20:43 Cogitri: We had this reported from both AMD and Intel users
20:45 Cogitri: The only package this happens with for me (with an AMD 5700 XT) is Chromium with hardware accel enabled since that apparently is the last thing using Xorg for me
20:45 Cogitri: Once I disable hw accel the artifacts disappear
20:46 Cogitri: I'm not 100% confident if the bug I commented on is exactly the same as what the reporter is experiencing though, their artifacts look a bit different to ours
23:21 airlied: imirkin: was there ever piglit tests for blend_equation_advnaced or just used deqp?
23:28 airlied: ah I see some fb fetch ones at elat