ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<cmarcelo> jekstrand: any progress on thinking about the volatile load_deref? one alternative for the two MRs there is to go even more specific and handle just load_deref+volatile for GCM + CSE(instr set).
<cmarcelo> Kayden: ^
ybogdano has joined #dri-devel
iive has quit [Quit: They came for me...]
ybogdano has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
ds` has quit [Quit: ...]
ds` has joined #dri-devel
off^ has joined #dri-devel
mhenning has joined #dri-devel
yuq825 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
oneforall2 has quit [Read error: No route to host]
oneforall2 has joined #dri-devel
xantoz has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
JohnnyonFlame has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
rsjw has quit [Quit: rsjw]
warpme____ has quit []
Company has quit [Quit: Leaving]
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
aravind has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
Akari has joined #dri-devel
reductum has quit [Remote host closed the connection]
reductum has joined #dri-devel
fxkamd has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
slattann has joined #dri-devel
ybogdano has joined #dri-devel
fxkamd has quit []
ybogdano has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
HdkR has quit [Remote host closed the connection]
HdkR has joined #dri-devel
dcz_ has joined #dri-devel
mhenning has quit [Quit: mhenning]
danvet has joined #dri-devel
bgs has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
itoral has joined #dri-devel
ahajda_ has joined #dri-devel
bgs has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
jlawryno has joined #dri-devel
kts has joined #dri-devel
tlwoerner_ has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
yuq8251 has joined #dri-devel
yuq825 has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
tlwoerner_ has quit [Ping timeout: 480 seconds]
tlwoerner has joined #dri-devel
Duke`` has joined #dri-devel
kts has joined #dri-devel
lemonzest has joined #dri-devel
tursulin has joined #dri-devel
<dolphin> airlied, danvet: Supplemental drm-intel-gt-next PR sent, tested to compile with both clang and GCC
ngcortes has quit [Quit: Leaving]
srslypascal is now known as Guest331
Guest331 has quit [Read error: Connection reset by peer]
srslypascal has joined #dri-devel
<emersion> mattst88: it seems like you didn't push the new tag, and didn't push the post version bump to 0.42.3
<emersion> for pixman
frieder has joined #dri-devel
sysescool has joined #dri-devel
srslypascal has quit [Quit: Leaving]
mvlad has joined #dri-devel
swalker_ has joined #dri-devel
jkrzyszt has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
swalker_ is now known as Guest335
oneforall2 has joined #dri-devel
srslypascal has joined #dri-devel
rasterman has joined #dri-devel
lynxeye has joined #dri-devel
swalker__ has joined #dri-devel
Guest335 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
JohnnyonFlame has joined #dri-devel
apinheiro has joined #dri-devel
vliaskov has joined #dri-devel
psykose has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
psykose has joined #dri-devel
pcercuei has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
kts has quit [Quit: Leaving]
MajorBiscuit has joined #dri-devel
<HdkR> https://www.phoronix.com/news/Intel-Arc-Graphics-No-POWER Took a while for normal users to notice it looks like.
slattann1 has joined #dri-devel
<HdkR> Was hoping this would have been solved by now :(
egbert has quit [Ping timeout: 480 seconds]
egbert has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
gawin has joined #dri-devel
<dcz_> does the vivante hardware support 2-byte textures even in principle? it should for YUV2:0:0, right?
<dcz_> 2-byte-per-pixel, that is
kts has joined #dri-devel
zx2c4 has joined #dri-devel
<zx2c4> any clever way of getting the connector/encoder current associated with the calling console/VT?
<emersion> what do you mean?
<emersion> a VT is not associated with a single connector
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Company has joined #dri-devel
<haasn> I'm trying to figure out how the VkDisplayKHR code in mesa works but I really don't understand it at all
<haasn> It seems to get away without ever deciding on or configuring a plane?
<haasn> the concept of 'planes' in vulkan terminology seems to just map to connectors in mesa, which is confusing
<haasn> (and redundant with VkDisplayKHR)
<haasn> I don't see any call to drmModeAtomicAddProperty(), nor any call to drmModeSetPlane(), nor drmModeGetPlane() or anything else related to planes
<emersion> haasn: it uses the legacy uAPI iirc
<lynxeye> dcz_: Vivante GPUs support all the usual 8/16/32 bit RGB formats + can directly sample from YUYV textures
<emersion> so drmModeSetCrtc and drmModePageflip, iirc
<dcz_> lynxeye: oh, thanks. I couldn't find a definite confirmation
<LaserEyess> emersion: really? ... why?
<emersion> which implicitly configures the primary plane
<emersion> LaserEyess: some drivers don't support atomic
<haasn> oh, I see
<emersion> I guess?
<haasn> emersion: is there any way to figure out which plane gets implicitly configured by this process?
<emersion> tbh these don't support vulkan
<emersion> I think
<haasn> context: I want to know what formats are supported
<LaserEyess> what is the overlap of drivers that don't support atomic but do support vulkan?
<LaserEyess> yes ol
<emersion> haasn: nope, it's the primary plane of the connector, always
<dcz_> lynxeye: currently, GBM fails to create a R16 texture, I'll try to add that
<emersion> LaserEyess: maybe amdgpu on older but not too old GPUs?
<dcz_> *a R16 buffer
<emersion> pretty niche
<LaserEyess> and they'd be using VkDisplayKHR? I mean, very niche...
<emersion> basically anything before GCN
<haasn> emersion: what API can I use to determine the "primary plane of a connector"?
<haasn> `drmModeConnector` doesn't seem to contain anything related to planes
<LaserEyess> I thought pre GCN wasn't supported by amdgpu?
<emersion> haasn: list planes, check possible_crtcs
<emersion> filter by type
<dcz_> lynxeye: now that I think of it, maybe I phrased the question wrong. What I'm looking for is a 16-bit depth grayscale texture as a sampler source
<haasn> is `possible_crts` a bitfield or what?
<emersion> sometimes a primary plane is compatible with multiple CRTCs
<emersion> haasn: yyp
<emersion> yup*
<emersion> the kernel docs explain that
<haasn> so the first plane on the list that satisfies (possible_crtcs & (1 << crtc_id)) is the primary plane?
<emersion> but no libdrm docs
<LaserEyess> haasn: based on this new information, I woudl say that writing a vulkan drm interop would be far, far easier than fixing mesa to use the atomic API for VkDisplayKHR
<haasn> yeah probably
<emersion> haasn: hm, doesn't work always
<emersion> why do you need to know?
<emersion> LaserEyess: why?
<haasn> emersion: I wanted to implement vkGetPhysicalDeviceSurfaceFormats2KHR
<emersion> haasn: oh, I see
<haasn> or rather, I wanted to extent it to support more than just bgra8888
<LaserEyess> emersion: first of all, would such a patch be accepted in mesa?
<emersion> LaserEyess: I'd review it
<haasn> so at the time of this call I need to know what formats are supported by a VkSurfaceKHR
<haasn> a VkSurfaceKHR is already associated with a unique connector (and associated crtc)
<emersion> haasn: I don't remember how one lists formats with the legacy uAPI
<LaserEyess> emersion: right, but my question is more: is supporting the niche usecase of no atomic API, but vulkan support what mesa wants to support?
<haasn> but to query the list of supported formats I need the right `uint32_t plane_index` to pass to `drmModeGetPlane`
<emersion> maybe something under CRTCs?
<haasn> I can't find anything else in xf86drm.h that lists formats
<haasn> besides this call
<emersion> LaserEyess: I'd say its fine to drop, maybe we can ask other contributors and see
<emersion> then maybe there was no way to list formats
<haasn> amazing :)
<haasn> I guess my pet project is doomed until somebody else (tm) rewrites the VkDisplayKHR code to support the non-legacy API
<lynxeye> dcz_: 16 bit per channel is a very different thing than 16bit per pixel ;)
<haasn> and until then I suppose I agree with LaserEyess that we should stop using VkDisplayKHR
<LaserEyess> haasn: or, you could do it in mpv
<LaserEyess> yes
<lynxeye> dcz_: I don't think R16 is supported for texturing.
<LaserEyess> most of the context_drm_egl code could be reused, most likely
<LaserEyess> you'd just have to change the egl bits to some common abstraction
<LaserEyess> and, truthfully, I was gonna work on that because I think that's required to set --drm-format at runtime in mpv
<haasn> fair
<haasn> leaves open the question of how to handle HDR metadata hinting when using the vulkan code
<dcz_> lynxeye: how can I find out? etnaviv_format.c has R16_UINT listed for "vertex + texture", but I don't know yet where that is used
<LaserEyess> I was also going to drop the legacy uAPI in mpv because the drivers that don't support atomic are oooooooooold
<haasn> because we now also no longer have the vulkan-based pl_swapchain
<haasn> so maybe what we need to expose is the ability to create a fully custom pl_swapchain that is driven entirely by the user
<dcz_> (I'm looking at mesa/src/gallium/drivers/etnaviv/etnaviv_format.c)
<haasn> either that or we create a new abstraction on top of pl_swapchain (like ra_swapchain) but without the ra baggage
<haasn> I guess I'm back to not caring about the issue, unfortunately
<LaserEyess> damn
<lynxeye> dcz_: Nope, it has R16I supported for texturing, which is a integer format. But since it's a EXT_FORMAT it will only work on GPUs with at least halti0 feature level, which is GC2000.
kts has quit [Quit: Leaving]
<dcz_> lynxeye: I seem to have Vivante GC7000 rev 6214, is that enough to have that feature?
<dcz_> when I tried to register the integer extension for use in the shader, I failed though
<lynxeye> dcz_: Yes, the GPU supports the texture format, but integer support isn't hooked up in the shader compiler, yet. :/
<dcz_> lynxeye: is this easy to hack in? I'm considering whether I should go back to patching my pixels manually for now :P
<dcz_> also, should GBM be failing to allocate a R16 buffer? that sounds like it shouldn't be very involved to fix
rasterman has quit [Quit: Gettin' stinky!]
itoral has quit [Remote host closed the connection]
yuq8251 has left #dri-devel [#dri-devel]
apinheiro has quit [Ping timeout: 480 seconds]
<mattst88> emersion: ah, I'll do both of those
<emersion> cool
fxkamd has joined #dri-devel
<dcz_> what does UNORM mean in formats? that it's converted to floats with 1 as maximum?
<tango_> yes
<tango_> it's converted to [0.0f, 1.0f] by dividing by dividing by the max of the bitwidth
jlawryno has quit [Ping timeout: 480 seconds]
Leopold has joined #dri-devel
Akari has joined #dri-devel
<dcz_> thanks
<MrCooper> "unsigned normalized"
<dcz_> UNORM or I doesn't even seem encoded in fourcc codes, so when importing a dmabuf, the driver can't make the decision to reject that yet
<dcz_> I'll move my questions to the bug tracker
<emersion> dcz_: i think fourcc are unsigned unless specified otherwise
<MrCooper> emersion: amdgpu supports atomic KMS with all supported GPUs, not sure it (i.e. DC) is enabled by default for Southern Islands yet though
<dcz_> yes, but that is the data format, and there seems to be another layer of format specifiers directing usage
<emersion> the only signed fourccs are floating point
<emersion> MrCooper:
<emersion> err
<emersion> MrCooper: oh i was under the impression that DCE was used on older GPUs
<dcz_> on my Intel GPU I use R16 but to the shader it's a float
<MrCooper> emersion: it is, but DC supports DCE, remember :)
pendingchaos_ has joined #dri-devel
<emersion> MrCooper: hmmmm. there's DCE-the-hardware, and DCE-the-impl-in-amdgpu, right?
<emersion> so DCE hw is supported by atomic DC?
<MrCooper> yes, no DCE-the-impl-in-amdgpu I know of though
<emersion> i didn't know!
<emersion> would be nice to have it on by default
ybogdano has joined #dri-devel
<MrCooper> I guess you mean the non-DC display code copied from radeon
pendingchaos has quit [Ping timeout: 480 seconds]
<emersion> right
<MrCooper> just checked, DC still isn't enabled by default for SI or CIK, because it doesn't support some of their connector types yet
<emersion> it's under a "dce" dir iirc
<emersion> oh, analog iirc
<MrCooper> the files are called dce_v<version>.c, they're in the amdgpu/ directory though
<eric_engestrom> emersion: "the only signed fourccs are floating point" -> but they don't _use_ the sign, do they?
<eric_engestrom> it's just a quirk of C
<MrCooper> emersion: right, analog and LVDS
<emersion> right, "dce" in the filename
pendingchaos has joined #dri-devel
<MrCooper> well, all HW specific code in that directory is in files named after the HW blocks :)
pendingchaos_ has quit [Ping timeout: 480 seconds]
warpme____ has joined #dri-devel
<agd5f> MrCooper, LVDS is working. It's just analog that is missing
<MrCooper> agd5f: cool, the comment in amdgpu_device_asic_has_dc_support is outdated then
<agd5f> yeah, I should fix that
<agd5f> well, I guess it may be sort of true. I'm not sure if some of the old DP to LVDS bridge chips are supported or not
<agd5f> but native LVDS is implemented
<dcz_> is indexing with fmt a terrible mistake, or have I lost my mind? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/etnaviv/etnaviv_format.c#L265
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Compy_ has joined #dri-devel
sysescool_ has joined #dri-devel
sysescool has quit [Remote host closed the connection]
lemonzest has quit [Quit: WeeChat 3.6]
sysescool_ has quit [Remote host closed the connection]
sysescool_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
xyb has joined #dri-devel
xyb has quit []
xyb has joined #dri-devel
xyb has quit []
slattann1 has quit []
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
off^ has quit [Remote host closed the connection]
elongbug has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
<zx2c4> emersion: what i mean is i'd like to create a dumb FB over whichever terminal currently just executed my program
jkrzyszt has quit [Remote host closed the connection]
<emersion> zx2c4: in multi-output setups, fbdev displays the terminal emulator on all outputs, mirrored
<zx2c4> oh, interesting
<zx2c4> so... not trivial to do i guess
MajorBiscuit has quit [Ping timeout: 480 seconds]
<zx2c4> currently i just take the first card in /dev/dri/card*, and then choose the first connected connector
<zx2c4> would like that process to be somewhat more automatic
jkrzyszt has joined #dri-devel
heat has joined #dri-devel
Duke`` has joined #dri-devel
<karolherbst> mhhh.. I we'll need a vec8/16 to vec4 lowering pass
<karolherbst> rusticl on v3d basically runs perfectly ewll
<jenatali> karolherbst: scalarize then vectorize?
<karolherbst> uhhhh...
<karolherbst> I'd rather not
<jenatali> Fair
bgs has joined #dri-devel
<karolherbst> just wondering if there is a quick way out or if that needs to be a new pass
<karolherbst> it's mostly like lowering to scalar
aravind has quit [Ping timeout: 480 seconds]
<pcercuei> I'm writing a DMABUF importer. After I create and add my (read) dma_fence to the dma_resv, can I start the device DMA process directly, or do I need to do something to make sure there is no write fence active?
<jenatali> I think the lower to scalar pass is actually just a specialization of lower to vec size
<pcercuei> dma_resv_wait_timeout() maybe?
ybogdano has quit [Quit: The Lounge - https://thelounge.chat]
<karolherbst> jenatali: right...
<jenatali> Like, in the source file I think it just uses a lower to vec size pass
<jenatali> (not in front of a PC)
<karolherbst> yeah and I have no idea how that stuff is even called... :D
<karolherbst> ehh..
<karolherbst> ohh, it's called nir_lower_io_to_scalar
<karolherbst> right..
<karolherbst> and nir_lower_alu_to_scalar
<karolherbst> jenatali: it was nir_lower_alu_width
<jenatali> Ah right
<karolherbst> yeah okay, so that one we can probably use to lower all vec8/16 alu ops to vec4
<karolherbst> still doesn't solve the io problem
<karolherbst> I think I'll need it for v3d, which seems to be vec4 and zink
<jenatali> Yeah we do io by lowering to 16-byte loads and stores (vec4 32bit) regardless of the original vec/bit size
<jenatali> Since that's what DXIL supports, though they did add 32-byte (vec4 64bit) at one point
<karolherbst> ahh.. right
<karolherbst> then I guess I can just copy paste
Leopold has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
<jenatali> Heh it's a pretty messy pass...
<eric_engestrom> we keep talking about the "amber branch" but its actual name was `staging/21.3`, not `amber`, so I've made a branch called `amber` with the stuff that was added on top of 21.3, and reset `staging/21.3` to its last release. The docs should now be clearer on that regard as well (!19507).
<eric_engestrom> tl;dr: don't send MRs against `staging/21.3` anymore, `amber` is now the amber branch :)
<eric_engestrom> (I have also redirected the currently in-flight MRs to the correct branch)
<illwieckz> oh thanks, I never found that so called amber branch
<jenatali> eric_engestrom: Good idea
<illwieckz> there was like, no branch, no tag, no folder named amber…
<illwieckz> ah a docs/amber.rst file had been added in september, I guess it can be updated to mention the new branch name
<illwieckz> the Building instructions are ambiguous
<illwieckz> I cannot guess by reading it if -Damber=true is for when building ambre branch or when building main branch
<eric_engestrom> amber=true on amber :)
<eric_engestrom> but I guess we should drop the option and hard-code that path on the amber branch
<illwieckz> or make it behaves that way by default
<illwieckz> I guess that people building amber without compat with main are even less than those building amber with compat with main (typically, distros)
<eric_engestrom> ah right, it can be turned off to provide the old versions of gallium & vulkan drivers
<eric_engestrom> ok, so not removing the option, but I'll post an MR to set it to `true` by default
<illwieckz> 👍️
mszyprow has quit [Ping timeout: 480 seconds]
<illwieckz> is nv30 still in main?
<gawin> yes
<illwieckz> great
<illwieckz> I may have bugs to report, I haven't tried recently but in my memories it was so broken that it was almost unusable. I'll have to test with latest main to check if that's still broken.
<eric_engestrom> if accepted I'll also update the docs on main
<illwieckz> also in my memories nv30 had EXT_framebuffer_object but no ARB_framebuffer_object and I wondered if the later could be implemented. I'll check those again.
kts has joined #dri-devel
<gawin> nv30 is prone to hardlocking, no idea from where it comes (super random and without errors in logs)
<ajax> illwieckz: from the code it looks like ARB_framebuffer_object support is a function of PIPE_CAP_MIXED_FRAMEBUFFER_SIZES, which nv30_screen.c sets to false
<ajax> which i think would be tough to work around if the hw support isn't there
swalker__ has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
<illwieckz> ah, because the nvidia driver for nv30 implements it
<illwieckz> (requires old distro though)
<illwieckz> (and is even more unstable than nouveau)
tzimmermann has quit [Quit: Leaving]
mvlad has quit [Remote host closed the connection]
fab has joined #dri-devel
<illwieckz> that would be surprising if nv30 didn't have hw support while ati r300 competitor had
<illwieckz> but on the other hand, it looks like nv30 drives both Rankine (GL 1.5) and Curie (GL 2.1)
<illwieckz> so maybe the disablement is for Rankine?
<illwieckz> and for some reason it was never enabled for Curie?
fab has quit [Ping timeout: 480 seconds]
<ajax> 2.1 didn't merge ARB_framebuffer_object, 3.0 did.
<illwieckz> but all other 2.1 mesa drivers provides ARB_framebuffer_object
<illwieckz> well, all, r300 and i965 for sure
srslypascal has quit [Quit: Leaving]
<illwieckz> ajax, can it be possible that nvidia worked around the hw to provide it?
<jekstrand> Is there a simple test/tool that scrapes modifiers from KMS?
<jekstrand> daniels, robclark, maybe? ^^
<daniels> jekstrand: drm_info
<jekstrand> sweet
<daniels> dare I ask why?
<daniels> (we should prob move that into a fd.o namespace)
<jekstrand> The nouveau kernel and nouveau GL and NVK can't agree on modifiers.
<jekstrand> I need to know what KMS is reporting
<robclark> daniels: or into libdrm/tests so it gets installed when you install modetest?
<daniels> robclark: bonus points for deleting the rest of libdrm/tests :)
<robclark> modetest is something I use regularly.. although I suppose drm_info might replace most of my use for modetest
srslypascal has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
<jekstrand> Ok, so kms matches mesa/main nouveau GL
<jekstrand> So WTH are these bogus modifiers coming from?!?
Akari has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
kem has joined #dri-devel
<jenatali> Ugh, dynamic uniformity... our software rasterizer does not like that
iive has joined #dri-devel
<jekstrand> Ok, so system mesa gives me bogus modifiers but my nvk branch is fine.
<jekstrand> *sigh*
<jekstrand> jenatali: Oh?
kts has quit [Quit: Leaving]
<jekstrand> Oh, well that's just cruel. :)
<jenatali> Yep
<jenatali> Porting the shader to HLSL, our old compiler fails to compile it because uniformity analysis says the barrier's not in uniform control flow... but DXC compiles it fine and validates my transpiled version too
<jenatali> Just our software rasterizer assumes the old rules
<jenatali> Which means I get to go learn another part of their compiler stack to go fix it I guess
<jenatali> I'm surprised llvmpipe doesn't choke on that
<jekstrand> Ugh... Modifiers drama just gets worse... Built Mesa 22.2 (the version my system claims to have installed) and it has the right modifiers
<jekstrand> Is Fedora carrying patches?!?
<airlied> jekstrand: karolherbst I think had some reverts to make tegra work
<karolherbst> airlied: yeah.. and I think it got fixed now
<airlied> not sure why fedora is carrying them, it's against policy to have them in the tree this long
<jekstrand> Yeah, there's 4 nouveau patches
<karolherbst> ohh right.. those patches need to be dropped now
<karolherbst> with that MR
* jekstrand really doesn't want to install Mesa system-wide so X11 will pick it up.
<jekstrand> Grrr...
<karolherbst> I can do a build later as I want to verify it on tegra anyway
<karolherbst> (through a copr)
<airlied> karolherbst: so we can drop them for 22.3 or did that patch go into a 22.2 release?
<jekstrand> It's got a fixes tag
<jekstrand> Looks like it's in 22.2.2
<Sachiel> that's a lot of 2s
<karolherbst> yeah.. let me try that out locally first so we don't regress tegra again, because that will only give me last minute blockers assigned to me
<jekstrand> hehe
<karolherbst> honestly, that already happend twice, and I'm not looking forward of that happening a third time 🙃
<jekstrand> Well, I don't particularly like spending several hours trying to figure out why my system mesa is bonkers only to discover Fedora is carrying bogus patches. :-P
<karolherbst> yeah.. that's on me and I totally forgot
<karolherbst> but I am also inclined nuking the tegra driver and use kmsro, but....
<jekstrand> But now that I know, I can start hacking blindly and hope there's a koji package for me to pull soonish.
<karolherbst> I'll build it on a copr and let you know once it's triggered
<jekstrand> +1
<karolherbst> f36?
<jekstrand> f37
<karolherbst> ahh, okay
mhenning has joined #dri-devel
<jenatali> Git question: is there a way to bisect changes to a certain part of the tree only?
<karolherbst> like a subdirectory?
<mattst88> jenatali: yeah, git bisect ... [<paths> ...] allows you to consider only commits that touch files in <paths>
<jenatali> Perfect, thanks
<mattst88> git bisect start, I mean
<mattst88> yw
<karolherbst> sadly using that in the kernel made me traumatized, so I'll never use it again :'(
<Sachiel> how?
<karolherbst> everything I used it with paths, I ended up with nonsense commits
<karolherbst> so I always had to do a full bisect afterall
<jenatali> Trying to bisect a regression in a part of Windows, and it was hanging trying to find revisions to test because our history is insane for the whole tree
<karolherbst> ahh yeah, the more reason to not use paths
* karolherbst never ever will use paths on git bisect ever again
ybogdano has quit [Ping timeout: 480 seconds]
<karolherbst> imagine you spend the entire day git bisecting your kernel to only find out it bisected to something entirely arbitrary not even removing one step in a full bisect
<agd5f> yeah, bugs can come from surprising places
<karolherbst> always expected the unexpected
ybogdano has joined #dri-devel
<karolherbst> jenatali: _but_ there is a cool thing about git bisect, and that's git bisect run, which allows you to ahdn in a script which decides good/bad based on the return code
<karolherbst> and if you mix that with compiling and handle broken build systems, it's even reliable
<jenatali> Yeah, I don't have the time/willpower to write a script to run a Windows subtree build and test this component, I'll just do it myself
<jenatali> Only 4 bisect steps with this subtree
<karolherbst> ahh.. not too bad
<karolherbst> as long as it doesn't take like 20 minutes to compile
<jenatali> I know the regression is a change I made, it's just over the course of a large chunk of feature work, and the crash is in jitted code with no symbols, so......
<jenatali> ~5 minutes :P
<karolherbst> you are a very luck person
<jenatali> Eh sometimes
<karolherbst> well at least this time
elongbug has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
lygstate has joined #dri-devel
ngcortes has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
ickle has joined #dri-devel
ickle_ has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
apinheiro has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
Guest69 is now known as frytaped
<karolherbst> jekstrand: build is done
gouchi has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<jenatali> \o/ finally got a packaged version of WARP that fixes my issues and doesn't regress, and I can finally land !19178
<karolherbst> nice
<karolherbst> jenatali: also, what do we want to do about the subpass stuff from !19381 ?
<jenatali> I'm fine with a subpass-dimension texture type
<karolherbst> right... but what about lower_input_attachments or should we just make it work? dunno if adding subpass-dimension texture type makes all that much sense
<karolherbst> dunno
<karolherbst> but I can try it first and see how that goes
Haaninjo has quit [Quit: Ex-Chat]
<illwieckz> ajax, what are the big differences between EXT_framebuffer_object and ARB_framebuffer_object that may explain a driver provides first one but not second one?
bgs has quit [Remote host closed the connection]
<airlied> illwieckz: the cap pretty much summarises it
<airlied> you have to be able to support different color and depth sizes
<jenatali> karolherbst: Doesn't lower_input_attachments just convert the custom intrinsics to tex ops? But leave the var types the same?
<jenatali> IIRC that's how we get into this mess...
<karolherbst> mhhhhhh... probably?
<jenatali> Our driver has special logic for still handling read-only images as textures, even though we should've converted all read-only images to textures using your nir pass, specifically because of this subpass case
<illwieckz> do we actually know if nv30 Curie doesn't have the hardware for ARB_framebuffer_object meaning the nvidia driver would emulate it (given it is known it provides it on such hardware)?
<karolherbst> illwieckz: caring to try out?
<illwieckz> karolherbst, what do you mean?
<karolherbst> I mean.. nobody probably knows this and one would have to try it
<illwieckz> so, how I can try it? =)
<illwieckz> I have a hardware set up and ready to test
<illwieckz> is there any risk for the hardware?
<karolherbst> 1. own a nv30 era gpu 2. cry because nothing works
<illwieckz> gnome-shell is completely broken on this XD
<karolherbst> I have like 5 of them and always try them all out, because 4 of them always break randomly
<karolherbst> not anymore!
<karolherbst> once I got my nv4x gpu to start gnome fine, but glxgears killed it ¯\_(ツ)_/¯
<illwieckz> oh
<illwieckz> let's try
<karolherbst> yeah.. with main it should be fine
<karolherbst> might see some artifacts
<karolherbst> but not this vertex wild west anymore
<karolherbst> fun part is, that this was broken since the initial code drop, lol
<illwieckz> I never seen it working yes
<karolherbst> try it, it might work now
<karolherbst> (good luck)
<illwieckz> I had some computers with nv30 on production, I used fbdev for years
<karolherbst> I think it was even pure luck I found this problem
<illwieckz> oh yes it looks far better!!!
<karolherbst> wait a minute, then it crashes
<illwieckz> well, it looked good until I've set a background image
<illwieckz> now I know why I disabled background images previously =)
<gawin> nv30 isn't so bad, ~100 fps on 7900gt in xonotic (as long as doesn't hardlock)
<karolherbst> opps
<karolherbst> *oops
<karolherbst> though I think gawin has one or two MRs still pending?
<gawin> nothing helpful I believe
<gawin> one for cleaning flags
<gawin> I remember someone made MR with fixes for loops, but iirc WIP
kseurer has joined #dri-devel
<karolherbst> right..
<karolherbst> the tricky part is figuring out what the actual bug is
kseurer has quit []
<illwieckz> so karolherbst how can I try ARB_framebuffer_object ? =)
<illwieckz> (I've forced PIPE_CAP_MIXED_FRAMEBUFFER_SIZES to return 1 and it was not enough XD)
karolherbst_ has joined #dri-devel
karolherbst is now known as Guest381
karolherbst_ is now known as karolherbst
danilo has joined #dri-devel
Guest381 has quit [Ping timeout: 480 seconds]
dakr has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
danilo has quit [Ping timeout: 480 seconds]
dakr has joined #dri-devel
Lyude has quit [Read error: Connection reset by peer]
Lyude has joined #dri-devel
krushia_ has quit []
<jekstrand> karolherbst: Subpass dimension texture ops make sense if drivers need to be able to detect those variables after the fact.
<illwieckz> ajax karolherbst I'm running Unvanquished with GL 2.1 and ARB_framebuffer_object on GeForce 6150 LE (Curie, NV4E)
<jekstrand> I think ANV does
krushia has joined #dri-devel
dakr has quit [Read error: No route to host]
dakr has joined #dri-devel
<karolherbst> okay, nothing against adding them, it's just something which sounds like work in random places until it all works :) though maybe I really just need the types and handle the conversion functions
Duke`` has quit [Ping timeout: 480 seconds]
<jekstrand> karolherbst: Ok, looks like I may have correct modifiers via EGL now. Time to see if other stuff breaks.
<karolherbst> have fun, I'm fighting with my jetson nano who doesn't want to finish booting :'(
<jekstrand> :(
dakr has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
dakr has joined #dri-devel
<jekstrand> karolherbst: Yeah, I get why they sound like work but also they should be very little work.
<karolherbst> yeah..
ahajda_ has quit [Read error: Connection reset by peer]
<karolherbst> I'll try to figure it out tomorrow
<karolherbst> jekstrand: also.. any idea on how we want to tacke vec8/16 to vec4 lowering?
<karolherbst> kind of painful having to fix every driver.. and zink needs it anyway
<karolherbst> was thinking about abusing the current to scalar passes somehow, but... maybe we also need something special for io lowering
<karolherbst> alu should be cheapish
<karolherbst> well.. cheap in terms of me spending time on figuring it out
<jekstrand> nir_lower_alu_width
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
<karolherbst> yeah, that's what I had in mind fo alu
<karolherbst> but what about io?
<jekstrand> tap-the-sign-meme.jpg
<karolherbst> heh
<jekstrand> There's like 3 drivers that have asked for that but no one has actually done the work. It's not that much work, I don't think.
<karolherbst> I just need it for close to everything though.. a tleast going from vec8/16 down to vec4
<jekstrand> yup
<jekstrand> Intel needs it to drop to vec4 or sometimes scalar based on $HEURISTICS
<jenatali> That looks pretty similar in goals to the pass we wrote for DXIL
<jekstrand> It's a pretty popular thing to do. 😅
<karolherbst> okay.. I just delegated testing my copr on tegra to somebody else
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
<jekstrand> hehe
* jekstrand is very confused by these compression modifiers
<airlied> the nvidia ones?
<jekstrand> yeah
<jekstrand> I e-mailed jamesjones
<jekstrand> There are 4 different compression modes, two for ROP/3D. There is 1 hardware bit. I am confused.
<airlied> ben might know on #nouveau if he's around
<jekstrand> nouveau is incapable of advertising compression. IDK about kernel.
<emersion> jekstrand: there was an XDC talk about these
<airlied> jekstrand: kernel driver is nouveau
<jekstrand> airlied: IDK if it's exercised there either
<jekstrand> I'm going to guess scanout doesn't support compression
<jekstrand> but I guess I could be wrong
fxkamd has quit []
<jekstrand> Yup, no compression modifiers in drivers/gpu/drm/nouveau
gouchi has quit [Remote host closed the connection]
apinheiro has quit [Quit: Leaving]
iive has quit [Quit: They came for me...]
gawin has quit [Quit: Konversation terminated!]
mszyprow has quit [Ping timeout: 480 seconds]
<illwieckz> with some luck the only reason why it wasn't enabled is that this driver also supports nv30 that doesn't support the feature and no one tried to enable it on nv40 before today