01:34 associatedwithsas: i think you do not want to negotiate with me, or say interact with me, cause you found nannybusiness solution to work, which is likely. I am not the judging instance here, i fluked that one out. 8 and 18 times higher values, which becomes very handy on real format, but clearing out something as to why that tends to happen so, might find ways to improve it, i am pathetic human being,
01:34 associatedwithsas: from hundred one, so yeah i know that it functions enough, but i am not quite satisfied with it entirely though probably it beats every solution. And i do not comprehend or understand why this behaves so, so obviously i ain't gonna critisize anyone over it too. but all sets work with it indeed.
01:35 associatedwithsas: if you are so resillient as me, you'd shit out at least one solution or have to etc. and this came with obvious fluke.
01:58 nougatcream: clearly something starts to happen on octal or decimal notation, if at single instance for last and if dual barrel for former, things start to combine then, which is entirely weirdo thing again. I am out of ideas at the moment but hope to understand later some day.
02:18 unliketheshadow: So it's meant to work as such: you either do 178+178+178+178=712 or do -32-32+178+178=292 their sum is hence 890 or 1602 which is times10 the value or times18 so times 10 and times8 all the sudden hop in, which is strange that same thing happens with 86 and 200 values again 860 and 688 and their sum is 18 times the value. So what immediately one can do is single buffer times8 and
02:18 unliketheshadow: subtract, then it can do one division by two, and then divide by 5 etc, such options. But considering the pdf of the real format which has flexible inputs, this only solution thus far could do still very good, but hope dies the last that someone improves it, i am so sick and tired i am not sure i can do it, and hence all the description side of this smells after wavelet transform of
02:18 unliketheshadow: some type.
03:18 rabbitbunsees: yeah true, nothing worked from my sets buns , time to quit meds, perhaps things go better then. Just wasted time, i am no science guy.
05:24 Company: so I watched all the ray tracing XDC talks, which had neat intros about how the instruction sets work on each of the GPUs. However, it's missing any info about how that layer works on nvidia - and googling only has links on how to use that stuff, not how it's implemented in hardware
05:24 Company: anyone has some useful links for that?
05:35 airlied: gfxstrand: ^ might know
05:35 airlied: there has been some re work on it, but not sure if anyone has documented it
07:30 vignesh: I pushed a commit (https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/6efda95a66c5651bb30c948d876b7239df9ec384) to drm-misc-next and it got merged https://gitlab.freedesktop.org/drm/misc/kernel/-/commits/drm-misc-next?ref_type=heads. But this error is seen https://paste.centos.org/view/89a65947. Do I need to resolve some conflict ?
09:00 MrCooper: in this scenario: 1. app draws to buffer using dGPU 2. Wayland compositor imports buffer into iGPU 3. compositor uses buffer for direct scanout, does the fence set to IN_FENCE_FD in step 3 need to cover any GPU work triggered by step 2, or does the kernel need to synchronize to that internally?
09:16 vignesh: jani:
09:16 vignesh: jani: looks like drm-intel has a conflict. Please see my message above
09:17 jani: vignesh: likely caused by someone else's push at the same time. I'll check
09:17 vignesh: jani: thanks
09:19 jani: vignesh: it's already been resolved
09:20 vignesh: jani: So I can just run dim update-branches ?
09:20 jani: vignesh: you can always run dim update-branches
09:20 vignesh: Okay thanks
09:21 jani: but I just ran dim rebuild-tip and it worked fine, so everything's good
09:21 jani: happy hacking ;)
09:21 vignesh: thanks :)
09:46 tzimmermann: jfalempe, hi. do you have comments on https://patchwork.freedesktop.org/series/145822/ ?
09:47 jfalempe: tzimmermann: sorry, I didn't notice this series, I will take a look today.
09:48 tzimmermann: ok, np
13:06 jfalempe: tzimmermann: sorry, I started to send the reviewed-by on the v1 :(, I will send again on the v2.
13:07 tzimmermann: yeah, there was a bug in v1. no worries about the r-b
13:43 S9: > 16:55 <MrCooper> S9: looks like a Mesa or kernel driver issue most likely, which version of Mesa is it?\nMrCooper: It's really curious, I replied but the message never came into logs. I was saying 24.3.2
13:47 S9: MrCooper: It's really curious, I replied but the message never came into logs. I was saying 24.3.2
14:53 zamundaaa[m]: MrCooper: there is no API to get a fence for that potential GPU work, besides implicit sync, right?
15:03 MrCooper: if implicit sync covers it, so should DMA_BUF_IOCTL_EXPORT_SYNC_FILE presumably
15:05 S9: MrCooper: What you meant when you said that it was a Mesa problem?
15:06 MrCooper: HW acceleration not working is most likely a Mesa issue
15:12 S9: MrCooper: Yeah, but I mean. It means that Mesa code don't support HWA or that my configuration of Mesa is borked?
17:08 zmike: nowrep: have you checked out https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33946 at all ?
17:15 nowrep: yeah, looks ok. can test it tomorrow
17:17 K900: If I may bump https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33890
17:33 alyssa: what are the feelings around uAPI to get fault info?
17:33 alyssa: particularly the fault address for page faults
17:33 alyssa: kgsl seems to have an ioctl for this
17:33 alyssa: radv straight up parses dmesg
17:33 alyssa: and nobody else seems to implement this yet
17:33 alyssa: i'm thinking that parsing dmesg is maybe.. *not* what we want to standardize on
17:34 dj-death: would be nice
17:34 dj-death: is there a VM object in DRM?
17:35 alyssa: there is in Xe ;)
17:40 jenatali: WDDM has such a uAPI, for what it's worth
17:40 alyssa: jenatali: generic or driver specific?
17:40 jenatali: Generic
17:41 jenatali: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/ns-d3dkmthk-_d3dkmt_getdevicestate
17:43 alyssa: neat
17:53 S9: How to get logs as of what fails to give hardware acceleration to userspace?
18:25 mattst88: S9: `LIBGL_DEBUG=verbose glxgears` will usually show you why the driver isn't loading
19:04 airlied: alyssa: 7a41ed8b59ba74ae36adc7f4688feff9e710cf76 seems to have added something to amdgpu
19:08 alyssa: airlied: oh nice
19:19 zmike: I have 4 drivers running glxgears with de-pointerized pipe_framebuffer_state
19:20 zmike: what I'm noticing so far is that pipe_surface objects really are pretty worthless
19:20 zmike: all the drivers just copy them around, but it's rare that they actually need any driver-side data
19:22 S9: mattst88: With LLVMPipe it's nothing but {,.}drirc not found. With Zink it's a littble bit more of the same thing but the window display nothing. And with anything else it's glx: failed to create drisw screen Error: glXCreateContext failed (and {,.}drirc)
19:24 S9: It's not really verbosy...
19:37 alyssa: zmike: yep!
19:56 airlied: zmike: yeah pipe_surface has always been that kinda wierd object, more than a resource, not quite a framebuffer
20:11 HdkR: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12800 Spicy regression. I thought it was a FEX bug so didn't report it initially :D
20:14 S9: Zink 8086 | ffffffff LLVMPipe; 46aa | ffffffff; Accelerated | Not; .7GB Memory | 16GB; Profile 4.6 | 4.5; Free memory .7GB | 31MB; Auxiliary memory 0 | 10GB; Dedicated memory .7GB | 149GB; Renderer Intel open source Mesa | 256 bits
20:14 robclark: alyssa: https://lists.freedesktop.org/archives/dri-devel/2025-February/493391.html perhaps?
20:16 S9: Zink GL_AMD_performance_monitor, GL_ARB_bindless_texture, GL_ARB_compute_variable_group_size, GL_ARB_fragment_shader_interlock, GL_ARB_sample_locations, GL_ARB_sparse_buffer, GL_ARB_sparse_texture, GL_ARB_sparse_texture2, GL_ARB_sparse_texture_clamp, GL_EXT_demote_to_helper_invocation, GL_EXT_depth_bounds_test, GL_EXT_semaphore, GL_EXT_semaphore_fd, GL_INTEL_shader_integer_functions2, GL_NV_compute_shader_derivatives, GL_NV_fr
20:17 S9: GL_NV_sample_locations, GL_OVR_multiview_multisampled_render_to_texture,
20:19 S9: LLVMPipe GL_3DFX_texture_compression_FXT1, GL_ARM_shader_framebuffer_fetch_depth_stencil, GL_ATI_texture_mirror_once, GL_EXT_shader_framebuffer_fetch, GL_EXT_shader_framebuffer_fetch_non_coherent, GL_EXT_shader_image_load_formatted, GL_EXT_texture_filter_minmax, GL_EXT_texture_mirror_clamp, GL_EXT_texture_sRGB_RG8, GL_EXT_texture_shadow_lod, GL_INTEL_shader_atomic_float_minmax, GL_KHR_blend_equation_advanced_coherent
20:19 S9: GL_NV_alpha_to_coverage_dither_control, GL_NV_shader_atomic_float,
20:21 S9: Some more of that. And LLVMPipe got exclusive chart line. And yeah, that's all
20:23 robclark: mlankhorst: looking at xe vm_bind vs devcoredump.. if I'm understanding this correctly, the gpuvm is updated synchronously (only pgtable updates is async).. so the vm snapshot devcoredump captures may not be accurate? What am I missing?
20:40 S9: Help only LLVMPipe works. Zink give black window and the others glx: failed to create drisw screen Error: glXCreateContext failed
22:47 pinchartl: when using a discrete GPU, separate from the KMS device, is there a way to get EGL to bridge the two, or do I need to render to a gbm surface (calling eglCreateWindowSurface() with the native handle set a surface created by gbm_surface_create) and then pass it to kms myself ?
22:48 pinchartl: (discrete GPU as in render-only device, e.g. Mali GPU on an ARM platform with a separate display controller)