00:52airlied: MrCooper: pulling gcc from testing seems to have unblocked it
03:41airlied: tarceri: hey, I'm seeing some meory leaks with gl_nir_link_uniform_blocks
03:41airlied: the ralloc context seems to be leaked
03:42airlied: though I'd only be slightly shocked if it was sometihgin llvmpipe was doing wrong
03:53tarceri: airlied: hmm was probably me sorry. I pushed a new change this morning maybe I missed a free will check
03:54airlied: tarceri: this might be a bit older
03:54tarceri: oh wait link uniforms? or link uniform blocks ?
03:55airlied: I'm not sure when I last rebased
03:55tarceri: is this for spirv support?
03:56airlied: yeah it was the cts spirv tests throwing the leak
03:57airlied: I can rebase and retest later, once it finished churning this other set of tests
03:57tarceri: ok I didn't write that code (I maybe reviewed it), and we dont use it yet for the glsl nir linker. It's not all that surprising that there is a leak
03:58tarceri: IMO the gl spirv support is pretty buggy
03:59tarceri: the testing offered by CTS and piglit seems pretty limited currently
03:59airlied: tarceri: ah cool, I'll reproduce it a bit better and file an issue
03:59airlied: tarceri: yeah I doubt anyone has ran cts under asan yet :-P
04:54Yuti: Can we get the drm bridge state if we have access to the drm_bridge and drm_connector?
07:24MrCooper: Lyude: do you really need depmod? The symbol checks performed by the kernel build system aren't enough?
07:26MrCooper: mareko: e.g. the linear modifier doesn't imply anything about pitch alignment, but different GPUs have different requirements for it, so there's a pretty good chance of pixel jumble when sharing even linear buffers between e.g. AMD & Intel GPUs
07:30emersion: i'd say it's perfectly fine to fail an import on invalid alignment, but i don't know how much that'd break
07:31emersion: daniels, danvet: would be nice to write down whether a modifier can encode alignment/placement/etc in drm_fourcc.h
07:31emersion: it seemed like there was a consensus
07:31danvet: emersion, sounds like a good idea :-)
07:32emersion: danvet: what's your take on this btw?
07:32daniels: yeah, it seems like it. FWIW (for agd5f_ in particular), one of the reasons why we don't encode alignment constraints is because it a) explodes the search space, and b) makes modifiers suddenly ambiguous. for instance, if you have a buffer whose pitch is 1024-aligned, and you have modifiers to encode the requirement to align to (32, 64, 128, 256, 512, 1024) pixels, then suddenly your buffer now matches 6 separate
07:32daniels: modifiers, because it's compatible with all of them.
07:33emersion: ah, that makes a lot of sense
07:34emersion: are there other good resons?
07:39emersion: it seems like the driver could somehow cope with the multiple-modifiers issue, righjt?
07:39emersion: your buffer could advertise the 1024-pixel aligned modifier
07:51daniels: well, it could, but the impedance mismatch is the real problem: modifiers by design are supposed to uniquely encode buffer layout, and the fact encoding constraints there makes them ambiguous suggests it's not quite the right hammer to use
07:52daniels: then you start pushing out from there to encoding contiguous vs. non-contiguous memory, other placement like hidden-VRAM vs. GTT/BAR vs. system memory ...
07:52daniels: soon we have 128-bit modifiers :P
07:53HdkR: Only 128bit? I'm sure you could easily push it to 128byte instead :)
07:55danvet: emersion, daniels yeah I think consensus is that modifier only encodes minimal alignment and stuff
07:55danvet: e.g. for tiles
07:55danvet: or for compression, where there's only one true way to do it for a given format because that's how the hw works
07:56danvet: but if you have stricter alignment constraints on some blocks than others, then encoding that in modifiers is wrong
07:56danvet: ofc import/use needs to then check that
07:56daniels: right, that's implicit in the definition - you can't have part tiles. we have the same restriction for linear as well, but given that linear has a tile granularity of 1x1px, no-one has yet managed to create buffers which don't satisfy that granularity requirement :P
07:56danvet: daniels, well linear for macroblock fourcc has larger alignment constraints
07:57danvet: yuv subsampling being the simplest example
07:57Zeising: eric_engestrom: ?
07:57daniels: danvet: conceptually the same if you ask me
07:58daniels: HdkR: round up to a page
07:59daniels: anyway, the core of modifiers is: they're opaque (to users) 64-bit tokens, you advertise a list of supported tokens, you intersect lists between different consumers to determine your acceptable set, you pass that set to a producer allocator who picks the locally 'best' one, and from then on in it only has a single modifier which is its modifier.
08:00daniels: so your only operations are intersect & eq
08:00daniels: if you have to go reasoning about their content, or if buffers now have multiple modifiers to them, that's something different
08:01danvet: yeah I think long term we probably can't avoid some accidental aliasing
08:01danvet: but really should try hard to avoid it
08:01pq: daniels, what about buffer start address alignment? Sound like you have been thinking only about pitch aligment.
08:01danvet: a modifier shouldn't be a subset of layouts of another modifier (like 64b aligned vs 128b aligned would be)
08:01danvet: but entirely disjoint layouts
08:02danvet: *describe entirely disjoint modifiers
08:03danvet: it becomes fun together with fourcc, and afbc modifier spec has declared specific (fourcc, modifier) combos as the one and only canonical combo for that reason
08:07daniels: pq: well quite, that's another thing, and placement, and protection, and ...
08:07daniels: danvet: well yeah, technically Y_TILED can alias Y_TILED_CCS with the same colour plane, just as presumably AMD can alias between non-DCC and fully-resolved DCC
08:08daniels: but that's not a fundamental property of the modifier itself, it's a transient property of the buffer content
08:08pq: it seemed like there was some confusion between people about which alignment was implied by a modifier
08:08danvet: daniels, I don't mean that kind of aliasing
08:08danvet: but e.g. for afbc argb and abgr is the same layout
08:08danvet: so there's only one combo for it that's considered canonical
08:09daniels: ah, right
08:10danvet: I think the Y-tiled CCS -> Y-tiled resolve operation is an entirely different thing
08:10danvet: atm we don't express anywhere that hw can do in-place transitions between modifiers
08:10danvet: I think that might also be useful for mareko for the CCS-for-rendering -> CCS-for-display transition
08:11danvet: vk resolve pass sounds kinda like a neat abstraction for that
08:11danvet: jekstrand, ^^ thoughts?
08:11danvet: also compositors aren't even close to caring about that kind of stuff right now I think
08:11daniels: I know lynxeye has previously typed up gbm_bo_copy for doing resolves outside the 3D engine
08:12daniels: since etnaviv/imx has an attached blit engine which can transition from supertiled (only RT output) to linear (only DC input)
08:12danvet: well not copies, but in-place
08:12daniels: different realisation but at least a similar problem class
08:13daniels: NV proposed an EGL (obviously) resolve API at XDC, but it was not enthusiastically received
08:13danvet: gbm sounds a bit fun, since you'd need some execution context for this on many gpus
08:13danvet: with priorities and all that
08:13danvet: daniels, wasn't it a "no way modifiers" approach?
08:13lynxeye: yea, GBM doesn't seem to be best place
08:14danvet: daniels, hm where/when was that?
08:14lynxeye: That EGL stuff seems useful if you want to do the transition in the compositor, but honestly I think we just want to provide feedback to the applciation
08:14daniels: danvet: Montreal, October :P
08:14daniels: tbf I've paged all the context out of my brain, I was pretty sick and rundown by the time XDC came around
08:14emersion_: lynxeye: agreed
08:15lynxeye: it will result in a few frames being suboptimal, but the steady state is what we mostly care about
08:15danvet: daniels, I can't find it to page the stuff back in
08:15daniels: lynxeye: yeah :) we've been going back and forth a lot on the Wayland protocol to do that this week, with emersion & ascent12 in particular working on it for protocol + Weston + Mesa
08:15emersion_: i think ascent12 wroe something about it
08:15danvet: lynxeye, yeah I think just getting to optimized steady state for compositors is almost all the win
08:15lynxeye: There is just no good way for the compositor to answer the question if a resolve (or even copy) is less work than doing a full render composition
08:15danvet: the in-place resolve can only help with some hiccup/dropped frames at best
08:16daniels: danvet: https://xdc2019.x.org/event/5/contributions/335/
08:17emersion_: also this: https://lists.freedesktop.org/archives/dri-devel/2019-October/239845.html
08:19danvet: daniels, thx
08:19daniels: ^ really good summary
08:21danvet: yeah modifier hints is what we need first
08:21danvet: then figure out the remaining bits if there's still a need
08:43tarceri: airlied: a quick look at gl_nir_link_uniform_blocks() and I can see it creates a memory context and never destroys it
08:44tarceri: airlied: allocate_uniform_blocks() should instead just pass NULL to rzalloc_array()
08:53emersion_: alright, sent a proposal, hopefully this is a good start
09:49danvet: hwentlan, agd5f_ [PATCH 2/2] drm/atomic-helper: reset vblank on crtc reset <- might be good if you can give this a spin on amd too
09:49danvet: just to avoid surprises
10:11bnieuwenhuizen: emersion: danvet: wrt uniqueness constraints, is the consensus that things also have to be unique for e.g. 1x1 textures?
10:12danvet: bnieuwenhuizen, well maybe not for those
10:12danvet: I mean eventually it probably gets a bit silly
10:12danvet: I guess there's also tiling formats where the difference only matters past a certain size threshold
10:13danvet: bnieuwenhuizen, fundamentally aliasing isn't a problem, as long as all drivers support all aliases
10:13danvet: in practice achieving that is a lot easier if we reduce aliasing as much as feasible
14:09mareko: MrCooper: we won't use the default linear modifier
14:10MrCooper: then you won't be able to share buffers with other drivers which support modifiers
14:10mareko: we shouldn't use it, or we should reject it if the alignment is wrong
14:10mareko: MrCooper: that's fine
14:11MrCooper: I don't think so :)
14:11mareko: MrCooper: AMD hw can't use them
14:11mareko: this is not a choice
14:13MrCooper: pitch alignment is orthogonal to modifiers, as the Daniels have been explaining
14:14bnieuwenhuizen: mareko: MrCooper: I think we should expose LINEAR and reject if pitch is too small, as modifier of last resort. When we select it, that means we'd have an empty modifier intersection anyway ...
14:15daniels: exposing LINEAR doesn't mean that you support literally every buffer which is linear, regardless of dimensions/pitch/placement/etc
14:15daniels: you can reject an import for any reason whatsoever
14:16bnieuwenhuizen: and we can keep allocating linear with the right pitch for AMD, just like the pre-modifier code, so AMD<->AMD will keep working in roughly the same way
14:16emersion: yeah, rejecting buffer import on bad pitch sounds like the better solution
14:45mareko: MrCooper: there is also BO alignment, which has to be queried from the kernel
14:46MrCooper: same thing as pitch alignment WRT modifiers I'd say
14:48kisak: poor Marge woke up on the wrong side of the bed and the scripting couldn't find the coffee pot ( https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5199#note_512426 )
14:49bnieuwenhuizen: kisak: sounds like the problem is more Gitlab: "Merge failed: Something went wrong during merge: 4:Deadline Exceeded. Please try again. "
14:51kisak: the commit is visible in cgit, so that's a plus at least
14:51MrCooper: right, it's that GitLab issue where the changes are merged in Git, but the MR doesn't reflect it
14:55daniels: yeah, I think some of the new services have created a load imbalance as well
14:58mareko: daniels: the EGL API for "resolve" is kinda required for any buffer sharing, because it adds much needed acquire-release semantic that other APIs with interop such as OpenGL-OpenCL and OpenGL-Vulkan interop have. EGL is the only weird one here
14:59mareko: daniels: before a shared buffer use withing the context, and acquire call is made, and after the use, a release call is made
15:00mareko: *daniels: before a shared buffer use withing the context, an acquire call is made, and after the use, a release call is made
15:01daniels: mareko: I agree shared FBOs do need an explicit flush/invalidate or acqrel, yeah
15:02mareko: if that API is missing, it can lead to suboptimal driver behavior or modifier selection
15:03mareko: and then all EGL apps would have to use it, such as the Chrome browser
15:22daniels: James's API proposal wasn't that though - it was an explicit 'transition from modifier A to modifier B'
15:23daniels: rather than 'do whatever you need to do to resolve from your current internal state, to something that can be externally sampled as your defined modifier'
15:29jekstrand: jenatali_: Can you pastebin (or gist or hastebin or whatever you prefer) the NIR you're seeing with extra 64-bit ALU in it?
15:30jekstrand: jenatali_: I may be able to identify what pass you need to run post-lower_io to clean it up
15:36bnieuwenhuizen: daniels: I interpreted that presentation very much as having groups of "closely related modifiers" that you may end up transitioning every frame (to switch between rendering and display?)
15:38kisak: nice, kwin 5.18.5 fails to build against mesa git master, but is fine with mesa 20.0.7. looks like symbols like EGL_TEXTURE_Y_XUXV_WL couldn't be found (likely a linking issue on kde's side)
15:39sravn: danvet: "drm/atomic-helper: reset vblank on crtc reset"
15:39karolherbst: kisak: does it include eglmesaext.h?
15:39sravn: Cannot reply, my ISP has marked the message as SPAM, likely due to too many receivers or such
15:39sravn: atmel-hlcl parts are r-b
15:39karolherbst: ehhh.. ufff
15:40jenatali_: jekstrand: Yeah, one sec. It seems that there's a preference for lowering away (unpack, do 32bit math, pack) into (do 64bit math), even though there's an extra unpack at the end of that sequence
15:40karolherbst: debugging stuff with libasan fails if the application uses SVM :/
15:40danvet: sravn, grab it from lore?
15:40danvet: or patchwork
15:40kisak: karolherbst: I don't know, just getting general updates done on a gentoo box ahead of mesa testing later today
15:40sravn: r-b here is not good enough?
15:40danvet: sravn, or do you mean your reply is caught by the isp?
15:41karolherbst: kisak: wait.. it fails to link?
15:41jekstrand: jenatali_: Weird.... That seems wrong.
15:41sravn: It is my reply that I cannot send, I have seen it before
15:41jenatali_: jekstrand: https://pastebin.com/YaWH0Vag
15:41danvet: sravn, ok I'll forward it
15:42kisak: karolherbst: yeah, died with "error: ‘EGL_TEXTURE_Y_XUXV_WL’ was not declared in this scope" and 3 others
15:42karolherbst: that's not a linking issue :p
15:42daniels: kisak: #include <EGL/eglext.h>
15:42sravn: Using function named __foo really hurts my eyes. __ signals "internal stuff" or lack of good naming to me
15:42karolherbst: daniels: it's in eglmesaext.h actually
15:42daniels: kisak: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4953#note_512473
15:42jenatali_: jekstrand: I haven't confirmed that that specific change was what caused 64bit ops to reappear after optimizations - I'm going to double-check
15:42danvet: sravn, we don't have any better idea unfortunately
15:42daniels: kisak: it's not
15:43sravn: I know this patch did not introduce the naming, but it introduce the use of a function named __foo in more places. Sigh
15:43danvet: sravn, the entire atomic state helpers work like this if you subclass a state
15:43daniels: kisak: it was originally included in eglmesaext.h by Mesa - but eglext.h included eglmesaext.h so you still got it via eglext.h
15:43daniels: kisak: when we upstreamed it, it moved into eglext.h
15:44daniels: the scenario I know of where this breaks is where you have eglmesaext.h installed by Mesa (which has it), and you have eglext.h installed by GLVND (which does not have it, and which does not include eglmesaext.h)
15:44daniels: the solution is to upgrade GLVND so it provides it
15:44karolherbst: or use glvnd :p
15:44kisak: daniels: thanks, that's it. I looked in the wrong place before mentioning it here
15:44karolherbst: in gentoo it's still optional
15:46jekstrand: jenatali_: It looks like something somewhere is replacing `u2u64(u2u32(x))` with `x & 0xffffffff`
15:46jekstrand: jenatali_: It also looks like there's a 64-bit multiplication happening
15:49jekstrand: jenatali_: I see what's happening now. It's the multiply for array offsets that's causing grief
15:49jekstrand: jenatali_: We could add a couple algebraic opts to clean it up if we wanted
15:49jenatali_: jekstrand: Yeah. Still seems like being explicit about what size the offsets should be is the simpler/safer thing
15:50jekstrand: jenatali_: Yeah, I'm thinking that's true now. Feel free to go back to having an offset_bit_size
15:50jenatali_: jekstrand: Thanks, working on it now :)
15:50jekstrand: One day, I'd like to have something which can turn most down-cast-of-alu into alu-of-down-cast
15:50jekstrand: Then this wouldn't be a problem
15:50jenatali_: Yeah, that'd be nice
15:51jekstrand: It wouldn't be hard to write, IMO
15:51jekstrand: We could do it with a giant pile of rules in nir_opt_algebraic but I think this is something that probably wants its own pass.
15:51mareko: I think it's too late for EGL, nothing can help it
15:51jekstrand: mareko: It's been too late for EGL for 10 years
15:51jenatali_: Currently WARP in our currently-released OS builds has a bug with 64bit shifts, which causes them to blow up, in addition to hardware out there with no 64bit support, so I'm trying to avoid 64bit as much as possible :)
15:52karolherbst: which GPUs actually have a fully native 64 bit alu?
15:53karolherbst: I think the only thing we've got on nv are 64 bit shifts and 32 bit adds with supports for carry bits
15:53karolherbst: and some bcsel stuff I think?
15:54jekstrand: jenatali_: Oh, sure. I'd like to see it avoided as well
15:54jenatali_: jekstrand: Opinions about the u2u64 on a 32bit constant for nir_deref_type_var, vs just using a 64bit constant?
15:54jekstrand: Which is why I'd love to see such an ALU pass so we get rid of all of it. :-)
15:55jekstrand: jenatali_: Just use a 64-bit constant
15:55jekstrand: jenatali_: Actually... You probably want to make build_addr_add assert that it's 32-bit
15:55jekstrand: So you probably want a 32-bit constant just so you can keep that assert.
15:55jenatali_: I had that in the version that used addr_get_offset_bit_size
15:56jenatali_: But the nir_deref_type_var produces an address, not an offset, so it doesn't run through build_addr_iadd
15:56jekstrand: Right, that one can just build an immediate
15:56jekstrand: Maybe assert(location <= UINT32_MAX)
15:56jenatali_: Sure, that works
16:02mareko: karolherbst: we have an instruction that does i64 = i32 * i32 + i64
16:02karolherbst: mareko: we... don't
16:02karolherbst: or.. maybe?
16:02karolherbst: I think we do
16:02karolherbst: well, kind of
16:03karolherbst: you can get the high or low bits of the 32 * 32 mul
16:03karolherbst: so you have two instructions and then merge the value...
16:10jenatali_: I'm actually not sure who has native 64bit ops
16:10imirkin: nvidia has native 64-bit atomic ops
16:10mareko: imirkin: everybody has those I think
16:11imirkin: nvidia has native 128-bit atomic ops :)
16:11imirkin: well, more like "op"
16:16bnieuwenhuizen: imirkin: which one? compare and exchange?
16:16imirkin: bnieuwenhuizen: i don't remember. iirc add.
16:17imirkin: i just remember being surprised
16:17bnieuwenhuizen:is now wondering if the generic cache-skipping 128-bit writes are atomic on AMD
16:18imirkin: actually looks like all atomics (or at least most) work with u128
16:18imirkin: on maxwell+
16:19imirkin: at least the ISA (decoder) supports it. the hw sometimes disagrees.
16:19imirkin: i haven't personally tested it
16:20imirkin: https://github.com/envytools/envytools/blob/master/envydis/gm107.c#L1894 -- and if you look up ed00sz, u128 is one of the options.
16:20imirkin: but perhaps not all combinatiosn with ops work
16:20karolherbst: imirkin: I think the 64 bit ones work at least
16:20karolherbst: I tested them recently
16:20imirkin: yes, those definitely do
16:20imirkin: iirc the 128-bit one was more limited
16:20karolherbst: might be
16:20imirkin: tehre might be some asserts in the emitter that cover it
16:21imirkin: i don't have the code handy
16:21karolherbst: probably VRAM only and stuff like that
16:21imirkin: well, gmem-only, obviously, no shared mem
16:21imirkin: (and atomics on local are just pointless)
16:21karolherbst: shared has working 64 bit cas though
16:22imirkin: yeah, on maxwell
17:07eric_engestrom: Zeising: I was just tagging you to show you that airlied did a libdrm release :)
17:10hat|: hey, my GPU decided to reset itself while playing, any idea what went wrong? here's the journal http://paste.awesom.eu/qSTN
17:19pepp: hat|: could be the same issue as the one reported here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2647
17:26sravn: danvet: was off for dinner. Yeah, so you say that if you subclass then the functions are named __foo. Not great that the recommended style force one to use the ill named functions. Maybe subclassing was not a thing in the past. Anyway, it is just the way it is and if I do not like it I could bite the bullet and post patches, which will not happen...
17:27danvet: sravn, we had exactly this discussions when atomic landed
17:27danvet: subclassing was part from day one
17:27danvet: outcome was: no one likes it, no one had a better idea
17:27danvet: definitely would be nice to have something
17:28sravn: OK, I will let it slip now. But maybe if I one day touch this code I may try to be creative
17:29danvet: sravn, yeah definitely
18:00Zeising: eric_engestrom: Ok, thanks. :)
18:05hanetzer: so. trying to get my 4k120hz monitor to work, amdgpu driver (foss on both sides), rx580 w/8gb ram
18:06hanetzer: its the kind that uses two cables (dp; I'm using dp 1.4 cables) and uses the TILE property to stitch itself back together.
18:39alyssa: does NIR pipe through GLES version (2 vs 3) to decide if NaNs should be flushed to zero / Inf clamped?
18:40alyssa: I see FLOAT_CONTROLS_SIGNED_ZERO_INF_NAN_PRESERVE_FP*, but that seems to be a SPIR-V thing
18:41HdkR: Paging Dr. jekstrand for GL floating point behaviour rules :)
18:43anholt_: does gles even have a flag for enabling flush to zero?
18:45hanetzer: HdkR: hey, was that you who recommended those dp cables?
18:45HdkR: hanetzer: Yea
18:45hanetzer: got 'em.
18:45hanetzer: now apparently there's an outstanding bug in the amdgpu driver to make tiled displays work properly :<
18:47jekstrand: HdkR: Hah!
18:47alyssa: anholt_: Er maybe not I think I misread the spec
18:48alyssa: Looks like the impl can decided to saturate *or* use a real inf
18:48alyssa: (For GLSL ES 1.0)
18:48anholt_: es3 gives you isinf/isnan, and you should be preserving inf/nan at least by then
18:49alyssa: For context, the mali blob sets "suppress inf/nan" flags if the shader is GLSL ES 1.0, but not if it's ES3
18:49alyssa: presumably to workaround GLES2 app bugs
18:50alyssa: glmark2-es2 -bterrain is badly broken for us if fp16 is enabled without suppressing inf, but if we set the flag like the blob it's fine, and fp32 is fine
18:51alyssa: poorly written app? sure. is our impl conformant here? yes. does it make sense to workaround anyway and still be conformant? not sure.
18:58hanetzer: just patch the standard to make the bug conformant ;P
18:58alyssa: hanetzer: the bug is conformatn :d
18:58hanetzer: agd5f_: hey, aren't you the amdgpu dude?
19:00imirkin: anholt_: my experience in GL is that ftz is required for regular fp32 ops
19:01imirkin: (which is separate from the inf/nan discussion, whereby DX9-based things assume that 0 * x = 0, even if x is infinity -- this is "solved" in different ways on diff gpu's)
19:01imirkin: wine wants to be able to control that, but i couldn't get amd/intel to sign on to implement the ext, so it never went anywhere.
19:02hat|: pepp: I got the same graphics card so that could be it
19:09HdkR: alyssa: I guess the question is more. Does NIR have this NaN definition (thus getting optimizations that can only occur one way or the other) or does each backend need to do magic around this and self-scope out which API is in use?
19:32imirkin: mareko: i obviously don't really know the details, but this looks odd to me -- https://cgit.freedesktop.org/mesa/mesa/commit/?id=a91306677c613ba7511b764b3decc9db42b24de1 -- based on the description (and the next line of code), i would have expected to use cu_mask[i][j], with only the cu_bitmap indices changed
19:35agd5f_: hanetzer, what's the question?
19:37hanetzer: agd5f_: tiled display. borked on amdgpu
19:38hanetzer: basically one half is where its supposed to be, the other is shifted half a screen upward (or downward, hard to tell), it all jitters, and each half sometimes swap the 'right position' 'shifted position' setup.
19:41agd5f_: hanetzer, file a bug: https://gitlab.freedesktop.org/drm/amd/issues
19:43hanetzer: I think it has been filed, and I think you're working on it?
19:44agd5f_: hanetzer, got a link>
19:44hanetzer: https://bugs.freedesktop.org/show_bug.cgi?id=110671 maybe this. need to locate the url again.
19:46hanetzer: also gitlab is hella laggy for me atm...
19:46hanetzer: https://gitlab.freedesktop.org/drm/amd/issues/781 I think this was it, but again, hard to check as the link keeps timing out.
19:46gitbot: drm issue 781 in amd "Regression: DP outputs out of sync on dual-DP tiled 5k screen" [Amdgpu, Bugzilla, Opened]
19:47imirkin: hanetzer: i saw some recent stuff about preferring dispid to other parts of edid with tiles
19:47imirkin: hanetzer: is this with recent kernels?
19:48imirkin: oh, maybe i'm thinking of "drm/edid: Fix off-by-one in DispID DTD pixel clock"
19:49imirkin: as well as a patch series from Ville in mid-march fixing DispID parsing
19:50agd5f_: hanetzer, this patch may fix it: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next&id=fd8f7c65a6c5438af474077cad5deb8652d116e1
19:50agd5f_: but I've had a hard time getting it reviewed by the display team
19:51hanetzer: yeah so I saw. I have already applied that, or does this require dc=1 ?
19:51hanetzer: this is a rx5800 gpu, btw.
19:52vsyrjala: + a few more dispid patches today
19:52agd5f_: hanetzer, rx580 (polaris) or rx5700 (navi)?
19:52imirkin: hanetzer: is that like 10 rx580's? :)
19:53hanetzer: agd5f_: polaris, I think. VGA compatible controller : Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev e7)
19:53hanetzer: achk. mistyped :)
19:53emersion: maybe try patch and add Tested-By?
19:54hanetzer: so dc=1 or dc=0?
19:54agd5f_: dc=1 (the default)
19:54hanetzer: amdgpu.dc=1 right now and same issue. kk. one sec. reboot.
20:02hat|: pepp: how safe is it to build master and use it for the workaround? Should I wait the next release?
20:06hanetzer: erm. I mean right now was dc=0. and yeah.
20:06hanetzer: I'll give it my ack :)
20:08hanetzer: now how do I properly scale this dual tile behemoth.
20:10hanetzer: there we go.
20:11hanetzer: agd5f_: emersion: WFM.
20:12mareko: imirkin: thanks
20:13emersion: ivyl: just FYI, it seemed like patchwork didn't understood this series https://patchwork.freedesktop.org/series/77361/#rev2
20:17ivyl: emersion: https://lists.freedesktop.org/archives/dri-devel/2020-May/thread.html#266499 seems like it only got the second patch out of two
20:17hanetzer: here's another question. my 'Screen 0' is too large (due to resizes with xrandr), is there a way to reduce it?
20:18ivyl: that's why it got confused with rev1, and then for rev2 it took the v2 which was sent without any x/y as the 1/2
20:18ivyl: cannot blame the robot, I would be baffled as a human too
20:18emersion: ah, but what happened here
20:19emersion: sorry for the fuss
20:19ivyl: patches 1/2 and 2/2 were sent as a top level patches
20:19emersion: ah, patch 1/2 is here https://lists.freedesktop.org/archives/dri-devel/2020-May/266498.html
20:19ivyl: 2/2 should be In-Reply-To: 1/2, which is the default git send-email behavior
20:20emersion: okay, i can see why this happens
20:20ivyl: no worries, thenks for letting me know
20:20ivyl: more often than not it's the patchwork being too naive in it's assumptions
20:25airlied: agd5f_: is that the fix 2 DPs on navi patch as well?
20:27agd5f_: airlied, don't know. fixes an issue with sync groups for tiled displays
20:33ivyl: emersion: now thinking about it, I'll write down all the patchwork's assumptions and expectations and I'll link to it in the incomplete/strange series message
20:34emersion: ivyl: ah, that'd be pretty helpful :)
20:34jekstrand: Oh, patchwork.....
20:34jekstrand:doesn't miss patchwork for Mesa
20:34hanetzer: agd5f_: what can I do to maybe help move that forward?
20:37ivyl: jekstrand: yeah, I hope we'll move on too :-P
20:41jekstrand: Patchwork: Simultaneously the worst tool imaginable and also the best there is at its job....
20:42alyssa: jekstrand: That's basically how I feel about computers as a whole.
20:42jekstrand: alyssa: touche
20:43imirkin: i need a computer that does what i want it to do, not what i tell it to do
20:45ivyl: wait till you get first DNN-generated HW
20:46imirkin:is holding his breath
20:47karolherbst: ivyl: nah.. those just execute "rm -rfv /" randomly
20:48bnieuwenhuizen: karolherbst: so how well would you like a machine that solves your problem 99.99% of the time and does "rm -rfv /" otherwise?
20:48bnieuwenhuizen:feels that that is how internet services are these days
20:48alyssa: bnieuwenhuizen: 99.99 seems high
20:49ivyl: karolherbst: I am fine with delete driven development - you keep removing stuff as long as all your tests pass
20:49alyssa: ivyl: I think it's more efficient to just keep removing tests until none fail.
20:49ivyl: deletion also happens on the test code though
20:50bnieuwenhuizen: alyssa: if your events are minutes that is still ~1 hour a year
20:50alyssa: Yeah, I spend much more than that fighting the machine
20:50bnieuwenhuizen: alyssa: luckily most of the time it doesn't work it doesn't delete the world either
20:52agd5f_: hanetzer, I'll try reviving the thread again
20:52alyssa: bnieuwenhuizen: Just yesterday I lost commits because a BO leak led to an OOM which required a hard reboot which led to disk corruption which led to .git irrecovably corrupting
20:56hanetzer: alyssa: :<
20:57ivyl: oh, that's unlucky :(
20:58alyssa: admittedly the commits were really bad, hence why they weren't pushed :p
21:08imirkin: alyssa: normally one talks about self-modifying code, but this sounds like self-deleting code
21:17alyssa: imirkin: >:
21:46jekstrand: bnieuwenhuizen, hakzsam, tarceri: Why is radv still using lower_ubo_ssbo_access_to_offsets?
21:47jekstrand: robclark, cwabbott: Same question for turnip ^^
21:48robclark: non-zero chance it was copied from radv
21:49airlied: jekstrand: is there a benefit in not using it?
21:49jekstrand: NIR can optimize SSBO access
21:49jekstrand: Also, it's a legacy path I'd very much like to delete from the SPIR-V parser
21:49jekstrand: IIRC, someone tried turning it off for RADV and saw pipeline-db regressions.
21:50anholt_: I've switched half the chezas in CI over to the new baremetal runner in prep for enabling pre-merge vulkan testing, let me know if you see a630 jobs get backed up.
21:50jekstrand: But zero work has gone into dropping it AFAICT
21:50jekstrand: We're carrying two different UBO/SSBO deref paths in spirv_to_nir right now because of it. :-(
23:06glisse: robclark: you remember off hand who is the maintainer for the overall arm architecture (not arm64)
23:06robclark: I doubt there is just one..
23:08glisse: well it seems there is one for every single soc
23:08glisse: i just do not want to spam bomb 20 people
23:12airlied: glisse: rmk for arm
23:39Lyude: has anyone tried building igt with clang before?
23:41airlied: that doesn't seem like something that would solve any problem I'd want :-P
23:42Lyude: airlied: cross compiling with gcc is more like a long running joke\
23:43airlied: Lyude: why are you cross compiling?
23:44airlied:avoids cross compiling anything that isn't the kernel due to the pain, compilers are rarely the problem
23:45airlied: Lyude: looks like it has a clang build in CI
23:45Lyude: airlied: trying to fix igt building on fedora ppc64le so the package can start updating again, mainly so we can use it for the other thing i'm working on that I can't mention here
23:46airlied: but why would that need cross compiling?
23:46Lyude: and i did not expect to spend this much time on it :\
23:46airlied: could probably do like we do for mesa with the igt CI
23:47airlied: does some ppc64le/s390 in qemu builds I think
23:47Lyude: airlied: i really don't like building stuff on other machines, because it either means I have to have my source files over nfs on the machine I'm building on, or send things back and forth, etc. and it just becomes kind of painful especially with how many scripts I have on my machine with hardcoded paths
23:48Lyude: also, probably should note my beef with cross-compiling on gcc is mainly around the fact there's basically no reason it shouldn't just support cross compiling for every arch out of the box like clang :s
23:48airlied: Lyude: in fedora I generally just pull the cross compilers from the distro
23:48airlied: it never seems that much work
23:48airlied: but I only really use them for the kernel
23:49airlied: Lyude: can't you just git clone on the ppc64le machine and fix it, and push from there?
23:49Lyude: airlied: yeah I just really would have liked to have this just, work in the future and not have to do that every time another arch breaks :\
23:50airlied: Lyude: then I'd probably spend time on adding ppc64le/s390 to CI like mesa does
23:50Lyude: mhm, if only I had time ;;. i am going to try doing that at some point
23:51airlied: it also depends on whether the problems are distro related or cross compiling related
23:51airlied: you can waste a lot of time fixing cross compiler issues that don't exist in the real world
23:51Lyude: also btw - i'm fairly sure the reason the cross compiler from fedora doesn't work is because they strip a bunch of stuff from it that you need for cross compiling anything that isn't the kernel, I remember I ran into this same issue with aarch64 building when I was doing panfrost stuff and I ended up having to use https://copr.fedorainfracloud.org/coprs/lantw44/aarch64-linux-gnu-toolchain/
23:52Lyude: apparently there is no ppc64le equivalent to that though
23:53Lyude: i'm going to try forking that, but if that doesn't work I'll probably just go to rsync and grumble
23:53airlied: it just seems like you aren't using git like "distributed" part of DVCS :-P
23:53Lyude: airlied: pardon?
23:54airlied: the mention of rsync
23:54Lyude: i have a feeling i'm about to realize i've been overlooking something extremely obvious
23:55airlied: I'm just not seeing what you are proposing I guess :-), whenever I deal with other architectures, I just git clone on the machine, do the work, and get out of there
23:59airlied: I have never nfs mounted, rsynced anything, granted I'm also usually on the other side of the world from those machines