00:08 newuser444467899: Uploaded file: https://uploads.kiwiirc.com/files/e26a3449b55170b26b1616c8acdbb431/pasted.txt
00:16 Sachiel: seems like a game issue to me
00:34 newuser444467899: Sachiel but if mouse accel change why i have same xinput list-props of my mouse
01:01 Sachiel: I don't know, but I don't see how that relates to anything graphics either
01:29 newuser444467899: i think something wrong with vulkan and vaapi
01:30 newuser444467899: cuz issue shows when i use vulkan or vaapi
01:30 Sachiel: neither of which relates to input at all
01:34 Lyude: pq: I may have misunderstood how drivers are actually handling this, I thought I had heard that was the plan but I haven't had the time to look at what i915 does right now (and don't remember where I heard that :S). so i might be wrong
01:34 Lyude: (also brb, rebooting server)
13:55 kallisti5: agd5f_: aw. Bummer. atombios parser in the drm driver is now full of drm stuff :-(
13:55 kallisti5: agd5f_: is there a clean version anywhere like it used to be? I've been trying to not "fork" it for Haiku
13:56 kallisti5: https://keybase.pub/kallisti5/atombios-drm.diff
14:42 udovdh: hello
14:43 udovdh: ninja mentions:
14:43 udovdh: meson.build:1759: WARNING: sensors option "true" deprecated, please use "enabled" instead.
14:43 udovdh: but when I use -Dlmsensors=enabled I get:
14:43 udovdh: ERROR: Value "enabled" for combo option is not one of the choices. Possible choices are: "auto", "true", "false".
14:43 udovdh: so what did I not understand?
14:43 udovdh: as lmsensors is the only sensors related option in
14:43 udovdh: meson configure . --prefix /opt/xorg/ -Dbuildtype=release -Ddri-drivers=[] -Dgallium-drivers=radeonsi -Dgallium-xvmc=auto -Dgallium-vdpau=true -Dgles1=false -Dgles2=true -Dgallium-xa=auto -Dgallium-opencl=disabled -Ddri3=true -Dplatforms=drm,x11,wayland -Dshared-glapi=true -Dglx=dri -Dglx-direct=true -Dgbm=true -Dosmesa=none -Dglvnd=true -Dlmsensors=enabled -Dvulkan-drivers=amd -Dgallium-va=true
15:01 kallisti5: agd5f_: this also looks like a typo
15:01 kallisti5: {0x1002, 0x6FDF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
15:02 kallisti5: the pciid looks potentially wrong. should be 0x67df
19:54 bernie_: emersion: where should the definitions from linux/include/drm/drm_color_mgmt.h go in the libdrm public headers?
19:55 bernie_: emersion: I need drm_color_encoding and drm_color_range to fill-in the values of hdr_metadata_infoframe
19:56 bernie_: Also, should I prefix it with drm_ in the drm public headers?
19:56 vsyrjala: drm_color_encoding is not part of the uapi
20:12 bernie_: vsyrjala: yeah, where should I put it?
20:13 bernie_: vsyrjala: or should I just copy-paste the enums in app code (like I've been doing)?
20:17 vsyrjala: they're internal to the kernel. something's sketchy if you think you need to use them in userspace
20:17 bernie_: oh, I figurd that the heades in include/drm are kept in sybc with 'make headers_install' from drm-next
20:19 vsyrjala: should be only include/uapi/drm
20:20 bernie_: vsyrjala: and, right, I don't really want drm_color_encoding and drm_color_range
20:20 bernie_: vsyrjala: but I do need hdmi_metadata_type and hdmi_eotf from hdmi.h
20:21 bernie_: vsyrjala: also not part of uapi, but needed to fill-in fields of hdr_metadata_infoframe
20:23 vsyrjala: right. those are just the values from the cta-861.3 (or whatever the spec number was)
20:23 bernie_: vsyrjala: I copy-pasted the other two because Kodi also did it: https://github.com/xbmc/xbmc/blob/17308087949a6789c3784789f41f23ba41568bfc/xbmc/cores/VideoPlayer/Buffers/VideoBufferDRMPRIME.h#L24-L35
20:23 bernie_: vsyrjala: they expected those to be part of uapi
20:23 vsyrjala: but since we have the struct laid out in the uapi header we should probably have these as well
20:24 vsyrjala: yeah. should be there i guess
20:24 bernie_: vsyrjala: also, emersion was surprised that hdr_metatata_infoframe was not prefixed with drm_
20:25 vsyrjala: yeah. the whole thing is snafu
20:25 bernie_: vsyrjala: i'm really clueless, but i'm happy to send patches to kernel / drm / drm_info to cleanup the headers
20:27 vsyrjala: i'd probably even suggest separate enums for hdr_output_metadata.metadata_type and hdmi_metadata_type1.metadata_type
20:28 vsyrjala: the latter should be the cta-861.3 spec number. the former something drm specific
21:24 karolherbst: what does translate the vertex attrib locations in gallium for nir? I have a shader putting a mat2x3 at location 14, but something in galliums turns that into a 28
22:04 karolherbst: uff.. seems like the vec16 work actually shows benefit to graphics as well for doubles: "VERT_ATTRIB_GENERIC0.abcdef" ... :D
22:05 karolherbst: now I am curious what happens with a mat3x4 type
22:05 imirkin: dmat4 still would need 2 of those :p
22:05 imirkin: time for vec32!
22:05 karolherbst: yeah..
22:05 karolherbst: :D
22:07 karolherbst: but I've also heard there is hardware with native vec8 and vec16 types....
22:07 karolherbst: so...
22:15 karolherbst: we we talk about nir_remap_dual_slot_attributes?
22:16 karolherbst: it produces invalid inputs: decl_var shader_in INTERP_MODE_NONE dmat2x3 in_vs_last (UNKNOWN.abcdef, 0, 0)
22:16 karolherbst: or should we just ignore the "type" and ignore this?
22:16 karolherbst: c
22:25 karolherbst: yeah... I think the logic behind nir_remap_dual_slot_attributes is just flawed
22:26 karolherbst: jekstrand: any thoughts on that?
22:33 karolherbst: jekstrand: I think it would be simplier to do the same we do in TGSI as well: just count the generic attribs from 0 and move on.. the location handling is totally bogus for vertex attribs anyway
22:34 karolherbst: and a complete mess
22:34 karolherbst: no idea why iris doesn't break or maybe all drivers have a workaround here.. dunno
22:34 karolherbst: at least right now I need to "type" to properly handle stuff...
22:39 Akari: Should I open a bug report? https://0x0.st/iWKl.png (Mesa 20.1)
22:41 jekstrand: karolherbst: I don't know what nir_remap_dual_slot_attributes doeds
22:41 jekstrand: Other than what's obvious from the name
22:42 karolherbst: jekstrand: yeah.. but that leads to GENERIC14 to be converted to GENERIC28 which doesn't exist
22:42 karolherbst: so nir print does this: decl_var shader_in INTERP_MODE_NONE dvec3 in_vs_last (UNKNOWN.xyz, 4, 0)
22:42 jekstrand: hrm...
22:42 karolherbst: but I guess there is an easy solution out here
22:43 jekstrand: Wait, doesn't that mean the app is doing something OOB?
22:43 karolherbst: nope
22:43 karolherbst: two vertex attribs
22:43 karolherbst: dmat2x3
22:43 karolherbst: one at location 0 and one at location 14
22:43 karolherbst: perfectly valid
22:43 jekstrand: Wait, so what is that bogus NIR pass doing?
22:44 karolherbst: and the application is the CTS :p
22:44 jekstrand: And who is calling it?
22:44 karolherbst: jekstrand: gallium calls it
22:44 karolherbst: for every vertex shader
22:44 jekstrand: grr.....
22:44 karolherbst: yeah...
22:44 karolherbst: I think we need to reindex first
22:44 karolherbst: then call it
22:45 karolherbst: in TGSI those two attribs are located at [0:7]
22:45 karolherbst: in nir at [0:3] and [28:31]
22:45 karolherbst: but I guess no driver actually cares about it and just looks are driver_location which is fine
22:45 karolherbst: but.. in nouveau we kind of care
22:46 jekstrand: still seems pretty bogus
22:46 jekstrand: You shouldn't multiply by 2
22:46 karolherbst: jekstrand: can you tell me off hand how the driver_location looks like for non generic attribs?
22:46 jekstrand: Oh, wait, vertex attribs... Thos might have different rules.
22:46 karolherbst: maybe I can deal with it that way.. but I'd rather see it fixed properly
22:46 imirkin: jekstrand: 1 vs input attribute slot != 1 "real" slot
22:46 imirkin: in GL
22:46 jekstrand: I keep forgetting GL is busted
22:46 karolherbst: yep
22:46 karolherbst: but now we run OOB in nir... so to speak
22:46 imirkin: it always felt like a pretty poor decision, at least for driver writers
22:47 imirkin: dunno if it makes things easier for users
22:47 jekstrand: karolherbst: I'm inclined to say "It's saturday" and also "I've done my time on this problem. I really don't want to go back and think about it again."
22:47 jekstrand: :-P
22:47 karolherbst: :D
22:47 karolherbst: fair enough
22:47 imirkin: jekstrand: i told karol to go to the beach instead :)
22:47 karolherbst: it's 1am here :p
22:47 FLHerne: Akari: Probably yes
22:48 karolherbst: I'll figure something out on... Monday.. depends how I feel tomorrow.. wheather is getting out of hand now
22:48 karolherbst: uhmm.
22:48 karolherbst: *weather
22:50 Akari: trying to record an apitrace to reproduce this... annoyingly enough this seems to only trigger under address sanitizer
22:52 Akari: maybe it'll be easier to just fix it myself :^)
22:53 Akari: actually i can't seem to trigger it anymore at all
22:59 imirkin: try wiping the cache
22:59 pendingchaos: Akari: maybe try setting the "MESA_GLSL_CACHE_DIR" environment variable to point to an empty directory?
22:59 imirkin: it seems to be something when writing the shader
23:00 imirkin: or that.
23:00 Akari: i found out how to trigger it reliably
23:00 Akari: it's literally 1 whitespace (linebreak) difference in the shader source
23:01 Akari: setting MESA_GLSL_CACHE_DIR to an empty directory still produces the crash
23:02 Akari: i'll see if i can construct a minimal reproducing program
23:11 imirkin: Akari: probably something to do with slightly different size and an incorrect <= vs < type thing somewhere
23:11 imirkin: assuming it's an issue in the actual blob writing
23:24 Akari: interestingly, my minimal reproduction program crashes in a similar way, but in a different place https://0x0.st/iWPK.png