#dri-devel on 2022-12-08 — irc logs at oftc.irclog.whitequark.org

2022-08-14 19:45 ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar

00:08 mbrost has joined #dri-devel

00:11 srslypascal has quit [Quit: Leaving]

00:15 <anholt> anyone know the gl cts code? Looking to add logging of an image, kind of lost how to do that when I've just got some readpixels data plus a format and type.

00:17 srslypascal has joined #dri-devel

00:17 jewins has quit [Ping timeout: 480 seconds]

00:17 Haaninjo has quit [Quit: Ex-Chat]

00:20 <airlied> anholt: tcu::TestLog::Image("Result", "Rendered result image", textureLevel.getAccess())

00:20 <airlied> is the sort of thing I see

00:21 jewins has joined #dri-devel

00:21 <airlied> just have to use tcu::TextureLevel

00:32 MrCooper has quit [Remote host closed the connection]

00:32 MrCooper has joined #dri-devel

00:32 pcercuei has quit [Quit: dodo]

00:37 djbw has quit [Read error: Connection reset by peer]

00:38 <anholt> airlied: oof. that's not going to play well with the test reading into a std::vector<GLtype> of components.

00:39 djbw has joined #dri-devel

00:42 <airlied> yeah probably need something like glu::readPixels(m_context.getRenderContext(), 0, 0, textureLevel.getAccess());

00:43 <anholt> I think I might be able to just log by whipping up a ConstPixelBufferAccess() around the existing readpixels data.

00:46 <airlied> Lynne: that ffmpeg transcode seems to produce an Rext h265 file that I can't play with vaapi

00:46 <airlied> oh maybe 10-bit

00:47 ybogdano has quit [Ping timeout: 480 seconds]

00:51 * airlied tries -profile main to no avail

00:51 mbrost has quit [Read error: Connection reset by peer]

00:51 <anholt> airlied: thanks, that pointer got me on track at least

00:56 shashanks_ has joined #dri-devel

01:02 shashanks has quit [Ping timeout: 480 seconds]

01:08 bbrezillon has quit [Ping timeout: 480 seconds]

01:08 <karolherbst> uhh... somehow fp16 is a bigger issue with radeonsi than I initially though it is. The translation of shifts to llvm can't really deal with vec2 fp16 things as it seems

01:10 <karolherbst> airlied: do you spot the soution for this line of code? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/llvm/ac_nir_to_llvm.c#L726

01:10 m_ has joined #dri-devel

01:10 <karolherbst> apparently the type check doesn't work inside LLVMGetIntTypeWidth

01:10 <karolherbst> (checks against int or something)

01:10 <airlied> oh is type a vector?

01:10 <karolherbst> yeah, vec2

01:10 <karolherbst> radeonsi vectorizes int16 types to vec2

01:10 <karolherbst> well.. fp16

01:11 m_ has quit []

01:11 <karolherbst> but also opts to general vec2 16 loads

01:11 mhenning has joined #dri-devel

01:11 <karolherbst> https://gist.githubusercontent.com/karolherbst/e3a6f9ae285c044dfac92e569812bb33/raw/6a3ccd2e0faf13e5cebb579cb28cbbf31155968e/gistfile1.txt

01:11 <karolherbst> "vec2 16 div ssa_29 = ishr ssa_27, ssa_28.xx"

01:11 <airlied> it's likely you coud work out from the nir side \

01:11 <airlied> instead of using llvm

01:12 <karolherbst> yeah... I think the question is rather if AMD hw can do vec2 shifts or if I have to scalarize that (or prevent vectorization of int16)

01:12 <airlied> ac_get_elem_bits should do it

01:12 <karolherbst> ahh... okay

01:13 <airlied> should at least allow you to make the hw die

01:13 <karolherbst> should be src[1] in the typeof anyway...

01:13 mhenning_ has joined #dri-devel

01:14 <karolherbst> now LLVMConstInt asserts

01:15 jfalempe_ has joined #dri-devel

01:15 mhenning has quit []

01:15 mhenning has joined #dri-devel

01:15 mhenning_ has quit []

01:15 <Lynne> airlied: oh, you're right, it does

01:15 <Lynne> how odd for x265

01:16 <Lynne> rext is meant to be backwards compatible, so it shouldn't really result in problems, but still, changing the profile in ways users don't expect is eh

01:16 <Lynne> use vaapi then

01:16 <airlied> Lynne: vaapi reports rext not supportde

01:16 <Lynne> ffmpeg -init_hw_device "vaapi=vp:/dev/dri/renderD128" -i <INPUT> -vf format=nv12,hwupload -c:v hevc_vaapi -keyint_min 1 -g 1 -vframes 240 -b:v 100M -an -y TEST_HEVC_INTRA.mkv

01:16 bbrezillon has joined #dri-devel

01:16 <Lynne> this will give you a regular Main profile

01:17 <karolherbst> airlied: I guess I'll figure out first if it's worth caring and if not try to split up those ops...

01:17 jfalempe has quit [Remote host closed the connection]

01:17 <karolherbst> though I guess the hw can do it, because it doesn't die on doing the same stuff with iadd

01:18 <karolherbst> airlied: do we have a helper to do scalar and vector consts for llvm?

01:19 <airlied> Lynne: I don't have a hevc encode profile for vaapi, I wonder why

01:19 <airlied> karolherbst: don't think so, we normally just build them using LLVMConstInt etc

01:21 <karolherbst> ehh...

01:21 <airlied> karolherbst: you could make an ac version of lp_build_const_int_vec

01:21 <airlied> don't think you can use the lp one directly

01:24 mhenning has quit [Quit: mhenning]

01:26 <Lynne> airlied: no other cards to use just to encode an hevc clip? even intel works

01:26 <airlied> Lynne: oh that's probbaly my own fault

01:26 <karolherbst> now to figure out if I have a vector or scalar with the C api...

01:26 mhenning has joined #dri-devel

01:27 <airlied> karolherbst: you sohuld be able to work that out from nir though

01:27 <karolherbst> uhh.. right

01:29 <airlied> Lynne: okay I think I have video file I can test with

01:30 <Lynne> if it says "Decoder capabilities for hevc profile "Main":' before the capabilities are printed you're good to go

01:30 <airlied> I'm in the h265 msg constructor on both sides now

01:31 <Lynne> msg constructor?

01:32 <airlied> the driver get_h265_msg function

01:35 yuq825 has joined #dri-devel

01:36 <airlied> Lynne: seeing pps differences around uniform_spacing_flag and loop_filter_across_tiles_enabled_flag

01:39 psykose has quit [Remote host closed the connection]

01:39 <karolherbst> "PASSED sub-test." :3

01:39 psykose has joined #dri-devel

01:48 columbarius has joined #dri-devel

01:50 co1umbarius has quit [Ping timeout: 480 seconds]

01:54 <karolherbst> airlied: do you think you can wire up aco or make radeonsi not consume image derefs while I'm on vacation? 🙃

02:05 <airlied> karolherbst: lols, probably not, but who knows, :-P

02:06 <karolherbst> heh

02:06 <karolherbst> airlied: alternatively I need a better solution for this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20161/diffs?commit_id=3cc18a9865598fa3375365623e2536c9eba52377

02:07 <karolherbst> anyway.. got my rusticl/si branch to pass an embedded CTS run now.. at least hte subtests (- the out of order one)

02:07 <karolherbst> and I even think about enabling radeonsi after that MR lands, because it's working fine for most things with that

02:09 <karolherbst> but the io lowering or rather samplers/textures being uniforms really makes it a huge pita issue :/

02:10 <Lynne> (on the topic of rusticl, hashcat makes nasty GPU crashes for me, even taking down the display controller)

02:11 <karolherbst> which GPU?

02:11 <karolherbst> but yeah.. I can imagine there being some annoying bugs still, but at least the CL CTS is more or less happy

02:12 <Lynne> 6900xt

02:12 <karolherbst> heh

02:12 <karolherbst> how are you running it?

02:12 <Lynne> with the case open

02:13 <karolherbst> what case?

02:13 <Lynne> computer case, cooling it down is nigh impossible

02:14 <karolherbst> okay sure, but I was actually wondering how you run hashcat

02:16 <Lynne> ah, mode 22000

02:17 <karolherbst> ehh.. assume I have no idea how to use hashcat, what do I need to do to trigger the crash you are experiencing

02:17 <Lynne> performance-wise, when it runs fine, I get around 2.2 1080TIs, which is a bit on the low side

02:17 <Lynne> oh, err, let me boot up my other machine to give you a command line

02:18 <karolherbst> if it doesn't run for several seconds the perf numbers might not be reliable

02:18 <karolherbst> also.. radeonsi compiles really really lazily, and I have some WIP patches to prevent that from messing up benchmarks as well

02:22 YuGiOhJCJ has joined #dri-devel

02:26 <Lynne> ./hashcat -m 22000 --self-test-disable -a 3 hash_test.hc22000 should trigger it

02:27 camus has joined #dri-devel

02:27 <karolherbst> "Hash 'hash_test.hc22000': Separator unmatched"

02:27 <karolherbst> anyway, it's not doing anything for me

02:28 <Lynne> yeah, you need a file

02:29 <Lynne> well, you can either capture one yourself, or you can just use some random sample I found, https://github.com/pavanjuluru143/pavanWPA2PSK/blob/main/handshake3.hc22000

02:30 <karolherbst> let's see what happens

02:30 <karolherbst> ahh yeah, my GPU starts to ramp up

02:31 <karolherbst> Speed.#1.........: 615.1 kH/s (0.00ms) @ Accel:512 Loops:1024 Thr:64 Vec:1

02:35 <Lynne> it's somewhat temperamental, if it doesn't cause crashes during startup, it won't in the future

02:35 <Lynne> keep in mind this was about 4 weeks ago when I tested it

02:35 flto has quit [Remote host closed the connection]

02:36 <Lynne> not sure if there were changes made to the branch, I got tired of rebasing it along with all other patches I have

02:36 <karolherbst> yeah... I fixed some annoying issues since then

02:38 <karolherbst> let's see how ROCm performs

02:38 <karolherbst> ah yes

02:38 <karolherbst> slower🙃

02:38 <karolherbst> ROCm: 550.7 kH/s (8.19ms) @ Accel:32 Loops:128 Thr:256 Vec:1

02:39 <karolherbst> Rusticl: 615.4 kH/s (0.00ms) @ Accel:512 Loops:1024 Thr:64 Vec:1

02:39 <karolherbst> don't mind the ms 🙃 I didn't properly implement profiling

02:39 Company has quit [Quit: Leaving]

02:40 flto has joined #dri-devel

02:44 off^ has joined #dri-devel

02:45 flto has quit [Quit: Leaving]

02:45 pjakobsson has joined #dri-devel

02:49 pjakobsson_ has quit [Ping timeout: 480 seconds]

02:49 flto has joined #dri-devel

02:52 jewins has quit [Ping timeout: 480 seconds]

03:08 <ishitatsuyuki> won? impressive

03:08 <ishitatsuyuki> that said, it's the same LLVM compiler under the hood

03:08 <ishitatsuyuki> (probably)

03:09 <karolherbst> yeah.. both are using llvm-15

03:09 <karolherbst> I'd be curious how ACO would perform, but for that we'd have to wire up aco for radeonsi first

03:09 <karolherbst> but from my earlier testing with zink I've got like 10% lower performance, but that could also be the overhead of zink+vulkan

03:10 <ishitatsuyuki> ACO's main problem is that it isn't ready for crypto related instructions I think

03:10 <ishitatsuyuki> just need a few more NIR algebraic plus custom instructions

03:10 <karolherbst> rusticl doesn't use them either

03:10 <ishitatsuyuki> LLVM can detect those patterns

03:10 <karolherbst> ahh yeah.. maybe

03:10 <ishitatsuyuki> circular shift is one

03:10 <karolherbst> depends a little on how much nir messed up the shader

03:10 <karolherbst> _but_

03:11 <karolherbst> the reason rusticl is faster is probably nir anyway

03:11 <ishitatsuyuki> :frog:

03:11 <karolherbst> yeah...

03:11 <karolherbst> I mean, I compile CL C to LLVM IR to SPIR-V to NIR and radeonsi turns that into LLVM IR 🙃

03:12 <karolherbst> and both rusticl and radeonsi run some opt passes on the nir shader

03:12 <karolherbst> but the most interesting part here is, that the nir shader almost looks like a normal GL compute shader

03:13 <ishitatsuyuki> the structurizer is doing a good job, perhaps

03:15 <karolherbst> yeah... or LLVM just isn't that great 🙃

03:16 <karolherbst> but I hope that ROCm structurizes as well? dunno... maybe they do all opts on unstructured code?

03:17 <karolherbst> I think the LLVM structurizer was especially added for GPUs back then? dunno...

03:18 <karolherbst> yeah.. it was initially a r600 private pass

03:19 <karolherbst> but yeah, I am actually impressed by the structurizer we've gotten. Whoever wrote the initial code: big thanks to you

03:55 yuq825 has quit []

03:57 <airlied> Lynne: ah those pps flags are not decoded by vaapi driver anyways

03:58 <Lynne> I did check them, and they did look fine to me

04:07 heat has quit [Read error: Connection reset by peer]

04:08 heat has joined #dri-devel

04:11 <Lynne> I think I got the ref frame structs to look fine, but still, the slot number is the major point of confusion

04:12 <Lynne> no one else refers to slotindex like this, not the specs, not other decoding APIs, none

04:12 <Lynne> in h264ese it was fine, there were frame_num and pic_id which directly corresponded to the concept of DPB IDs

04:13 <Lynne> but hevc simplified and yet made more complex the way DPBs are assigned

04:17 * airlied has even less knowledge of hevc than h264, I've at least stared at two hw h264 decode paths

04:20 <Lynne> me neither, both of them are too low brow and mainstream for my tastes

04:20 <airlied> guess we should start speccing AV1 vulkan then :-P

04:21 <airlied> which is actually one of motiviations for getting it off the ground

04:23 Jeremy_Rand_Talos_ has quit [Remote host closed the connection]

04:23 Jeremy_Rand_Talos_ has joined #dri-devel

04:24 <Lynne> what I'd really like to see is exposing theh film grain functionality as a separate command

04:25 <Lynne> but more likely than not, it'll just be a requirement where decoding av1 would require DISTINCT decoding mode

04:26 <Lynne> by the way, how are encoders exposing their vendor-specific options with vulkan encode?

04:26 nchery has joined #dri-devel

04:26 * airlied hasn't dug into encoders at all yet

04:37 <airlied> Lynne: there are a bunch of usage flags and tuning flags

04:38 <airlied> and capability flags, maybe they try to standardise the vendor specific bis

04:38 <Lynne> still seems kinda limited to what nvdec has as an options list

04:38 <Lynne> btw do you think there would be an issue if the slices data buffer was sparse?

04:39 <airlied> I think that should be fine

04:44 slattann has joined #dri-devel

04:44 <Lynne> updated my repo, if you do get keyframes to decode properly, check out line 659 in vulkan_hevc.c

04:44 <Lynne> ref_slot is the questionable number

04:45 <Lynne> that's it for me tonight, an hour early than yesterday, it's progress, but mornings are for sleeping through anyway

04:51 aravind has joined #dri-devel

04:55 <airlied> Lynne: cool, not sure I'll be making much headway today, somehow caught another illness,

05:03 columbarius has quit [Ping timeout: 480 seconds]

05:05 columbarius has joined #dri-devel

05:06 <airlied> Lynne: I think I got it seems related to pcm_sample_bit_depth_luma_minus1 and pcm_sample_bit_depth_chroma_minus1;

05:06 <airlied> hardcoding those to 0

05:06 slattann has quit [Read error: Connection reset by peer]

05:07 <airlied> Lynne: pushed a hacky fix to my branch, but I think it needs fixing on ffmpeg side

05:08 <airlied> looks like pcm.bit_depth might be 0

05:08 slattann has joined #dri-devel

05:09 <airlied> or maybe I should key it off pcm_enabled_flags

05:09 <airlied> let me try that

05:09 kts has joined #dri-devel

05:11 Nyaa has joined #dri-devel

05:12 <airlied> Lynne: okay pushed that fix to the branch, I frames seem good now

05:34 heat has quit [Ping timeout: 480 seconds]

05:43 <airlied> Lynne: it look like the current picture slotIndex isn't set properly

05:44 <airlied> I hacked the first call to vk_hevc_fill_pict and I'm seeing some better decoding (still broken)

05:45 aravind has quit [Ping timeout: 480 seconds]

05:45 slattann has quit [Read error: Connection reset by peer]

05:50 nchery has quit [Remote host closed the connection]

05:50 slattann has joined #dri-devel

05:50 nchery has joined #dri-devel

05:51 maxzor has quit [Ping timeout: 480 seconds]

06:11 mhenning has quit [Quit: mhenning]

06:13 bgs has joined #dri-devel

06:14 Akari has joined #dri-devel

06:19 junaid has joined #dri-devel

06:19 ngcortes has quit [Read error: Connection reset by peer]

06:19 rmckeever has quit [Quit: Leaving]

06:21 pekkari has joined #dri-devel

06:22 danvet has joined #dri-devel

06:24 slattann1 has joined #dri-devel

06:26 Duke`` has joined #dri-devel

06:27 fab has joined #dri-devel

06:30 slattann has quit [Ping timeout: 480 seconds]

06:31 pekkari has quit [Quit: Konversation terminated!]

06:32 pekkari has joined #dri-devel

06:38 Duke`` has quit [Ping timeout: 480 seconds]

06:57 <tjaalton> dcbaker: hey, will there be a final 22.2.x release soon?

07:03 bgs has quit [Remote host closed the connection]

07:05 Nyaa has quit [Remote host closed the connection]

07:05 Nyaaori has joined #dri-devel

07:07 camus has quit [Read error: Connection reset by peer]

07:08 camus has joined #dri-devel

07:19 dcz_ has joined #dri-devel

07:23 fab has quit [Quit: fab]

07:24 yuq825 has joined #dri-devel

07:29 junaid has quit [Remote host closed the connection]

07:32 off^ has quit [Remote host closed the connection]

07:34 alanc has quit [Remote host closed the connection]

07:34 alanc has joined #dri-devel

07:36 junaid has joined #dri-devel

07:41 rasterman has joined #dri-devel

07:54 ppascher has quit [Ping timeout: 480 seconds]

07:56 fab has joined #dri-devel

07:59 camus1 has joined #dri-devel

07:59 camus has quit [Read error: Connection reset by peer]

08:02 tzimmermann has joined #dri-devel

08:05 junaid has quit [Ping timeout: 480 seconds]

08:12 tursulin has joined #dri-devel

08:19 fab has quit [Quit: fab]

08:30 jlawryno has joined #dri-devel

08:45 vliaskov has joined #dri-devel

08:55 slattann1 has left #dri-devel [#dri-devel]

08:56 <Siddh[m]> siqueira: Hi, I have a query regarding xorgevoc and amdgpu tests. I had emailed you (and melissawen) regarding it, could you please take a look at it?

08:59 Leopold_ has quit [Remote host closed the connection]

08:59 Leopold_ has joined #dri-devel

09:00 lynxeye has joined #dri-devel

09:02 <MrCooper> DemiMarie: they need to use compute APIs with corresponding guarantees, and workstation-grade GPUs with error correction/detection

09:04 sarahwalker has joined #dri-devel

09:06 swalker_ has joined #dri-devel

09:07 swalker_ is now known as Guest1334

09:13 sarahwalker has quit [Ping timeout: 480 seconds]

09:21 heat has joined #dri-devel

09:28 fab has joined #dri-devel

09:30 fab has quit [Read error: Connection reset by peer]

09:30 fab has joined #dri-devel

09:31 MajorBiscuit has joined #dri-devel

09:38 <DemiMarie> MrCooper: which APIs provide such a guarantee? CUDA? OpenCL? HIP?

09:50 fab has quit [Quit: fab]

09:51 fab has joined #dri-devel

10:03 fab has quit [Quit: fab]

10:03 fab has joined #dri-devel

10:06 Akari has quit [Quit: segmentation fault (core dumped)]

10:12 shashanks__ has joined #dri-devel

10:12 shashanks_ has quit [Read error: Connection reset by peer]

10:16 fab has quit [Read error: No route to host]

10:16 fab has joined #dri-devel

10:21 shashanks__ has quit [Ping timeout: 480 seconds]

10:21 <ishitatsuyuki> DemiMarie: It's the libraries (sometimes standard library functions too), really. GPUs inherently have non-deterministic execution order between threads, so you need to avoid any techniques that doesn't fully commute (e.g. atomicAdd)

10:21 <Lynne> airlied: you're right, that is hacky

10:22 <Lynne> shouldn't the device itself ignore pcm if not enabled?

10:26 fab has quit [Ping timeout: 480 seconds]

10:28 fab has joined #dri-devel

10:31 jkrzyszt has joined #dri-devel

10:33 fab has quit [Quit: fab]

10:34 Guest1340 has joined #dri-devel

10:43 Guest1340 has quit []

10:49 shashanks has joined #dri-devel

10:57 shashanks has quit [Ping timeout: 480 seconds]

10:58 junaid has joined #dri-devel

11:04 Company has joined #dri-devel

11:07 <melissawen> Hi Siddh[m], I don't plan new mentorships in the next rounds. But I can say the KUnit test coverage for amd display is still small, so there's a lot of room to work on unit tests there.

11:07 shashanks has joined #dri-devel

11:08 <melissawen> due to the nature of unit testing, I see you won't need many subsystem concepts to start to contribute

11:09 <melissawen> and that's what happened to our mentees this year

11:10 junaid has quit [Quit: leaving]

11:10 junaid has joined #dri-devel

11:11 <melissawen> I don't know siqueira's plans for the next year, but you can also check mairacanal and tonyk plans on DRM/KUnit mentorship

11:13 junaid has quit []

11:13 junaid has joined #dri-devel

11:14 junaid has quit []

11:14 junaid has joined #dri-devel

11:15 shashanks_ has joined #dri-devel

11:16 shashanks has quit [Read error: Connection reset by peer]

11:17 kts has quit [Quit: Leaving]

11:20 <mairacanal> Siddh[m]: sorry for the late reply! "what is the implicitly expected level of familiarity with GPU code, kernel, and/or testing in general for someone to consider applying in the first place?" -> As melissawen pointed out, I don't believe that you need huge familiarity with GPU code, but I would say that familiarity with the kernel contribution

11:20 <mairacanal> workflow and C knowledge is essential. Moreover, it is also good to have some familiarity with the KUnit API, which has some great documentation. I believe that before applying it, it is nice to have some small contributions to the DRM, in order to learn the mailing-list workflow and learn how to build the kernel.

11:30 junaid has quit [Remote host closed the connection]

11:36 shashanks_ has quit [Ping timeout: 480 seconds]

11:39 heat has quit [Remote host closed the connection]

11:39 heat has joined #dri-devel

11:46 jlawryno has quit [Remote host closed the connection]

11:46 jlawryno has joined #dri-devel

11:54 nils__ has joined #dri-devel

11:57 jlawryno_ has joined #dri-devel

11:58 nils__ has quit []

11:58 co1umbarius has joined #dri-devel

12:00 columbarius has quit [Ping timeout: 480 seconds]

12:00 kts has joined #dri-devel

12:02 jlawryno has quit [Ping timeout: 480 seconds]

12:03 ishitatsuyuki has quit [Quit: No Ping reply in 180 seconds.]

12:05 ishitatsuyuki has joined #dri-devel

12:06 kts has quit [Quit: Leaving]

12:08 jlawryno_ has quit [Remote host closed the connection]

12:08 jlawryno_ has joined #dri-devel

12:08 Didgy has joined #dri-devel

12:09 <Didgy> Hey guys, I'm new. I'm hoping to get started with learning GPU driver development the coming year

12:10 ishitatsuyuki has quit [Quit: No Ping reply in 180 seconds.]

12:11 ishitatsuyuki has joined #dri-devel

12:17 <mupuf> Didgy: I see you have chosen the path of the dark side! Put aside your sanity, you will not be needing it where you are going ;)

12:18 <Didgy> Yeah, that's my other acquintances are saying as well, but I'm eager to learn

12:19 <Didgy> Currently just getting familiar with building Mesa

12:19 <mupuf> More seriously, find a GPU you care about, deploy the latest versions of every compnent of the driver, find an app that doesn't work because of a missing feature, learn about the feature, learn about the driver, and get cracking

12:19 <Didgy> I'm not familiar with drivers at all, but I'm fairly familiar with writing Vulkan applications

12:19 <Didgy> Any resources you guys have to recommend would be appreciated

12:20 <Didgy> My goal is to contribute to the PanVk driver, but I'm starting with just learning about the Intel driver first

12:20 <mupuf> well, if you have used Vulkan, you are already in a good place

12:20 <mupuf> Not sure there is much value in learning a driver first to better learn about another one later

12:21 jlawryno_ has quit [Ping timeout: 480 seconds]

12:21 <Didgy> I have a Rock 3A SBC at home, I'll be able to use that for learning after New Years

12:21 <Didgy> I'm just not very familiar with the Mesa project at all, so I figured I'll just start somewhere while I'm waiting to use that

12:21 <mupuf> I see! Well, you can definitely learn about deploying mesa in the mean time

12:23 <Didgy> I'm also not used to communicating over IRC and mailing-lists, so that's going to be new

12:24 ishitatsuyuki has quit [Quit: No Ping reply in 180 seconds.]

12:25 ishitatsuyuki has joined #dri-devel

12:29 <mupuf> Well, enjoy your time of discovery!

12:32 jlawryno_ has joined #dri-devel

12:39 jlawryno_ has quit [Remote host closed the connection]

12:40 jlawryno_ has joined #dri-devel

12:41 Guest1350 has joined #dri-devel

12:41 srslypascal is now known as Guest1351

12:41 srslypascal has joined #dri-devel

12:46 Guest1351 has quit [Ping timeout: 480 seconds]

12:46 flibit has joined #dri-devel

12:48 Didgy has quit [Quit: Konversation terminated!]

12:52 flibitijibibo has quit [Ping timeout: 480 seconds]

12:52 jlawryno_ has quit [Ping timeout: 480 seconds]

12:58 kts has joined #dri-devel

13:01 ppascher has joined #dri-devel

13:05 pcercuei has joined #dri-devel

13:18 rsalvaterra has joined #dri-devel

13:19 jkrzyszt has quit [Remote host closed the connection]

13:27 kts has quit [Quit: Leaving]

13:29 dliviu has quit [Read error: No route to host]

13:30 dliviu has joined #dri-devel

13:32 zarast has quit []

13:33 zaratustra has joined #dri-devel

13:34 OftenTimeConsuming has quit [Remote host closed the connection]

13:35 maxzor has joined #dri-devel

13:37 jkrzyszt has joined #dri-devel

13:38 OftenTimeConsuming has joined #dri-devel

13:38 Leopold_ has quit [Remote host closed the connection]

13:38 agd5f has quit [Read error: Connection reset by peer]

13:38 maxzor has quit [Remote host closed the connection]

13:38 maxzor has joined #dri-devel

13:38 Leopold_ has joined #dri-devel

13:45 sgruszka has joined #dri-devel

13:49 <Siddh[m]> <melissawen> "and that's what happened to..." <- Thanks for the clarification!

13:49 <Siddh[m]> <melissawen> "I don't know siqueira's plans..." <- Sure, I'll check out.

13:51 YuGiOhJCJ has quit [Quit: YuGiOhJCJ]

13:51 <Siddh[m]> <mairacanal> "Siddh: sorry for the late reply!..." <- Thanks. I do have some familiarity with kernel's workflow, I have a few bug fixing patches in mainline and stable already. I'll try to see if I can get in some contributions to DRM.

13:58 maxzor has quit [Remote host closed the connection]

13:58 maxzor has joined #dri-devel

13:59 agd5f has joined #dri-devel

14:00 minecrell8 has quit []

14:00 maxzor has quit [Remote host closed the connection]

14:00 minecrell has joined #dri-devel

14:00 maxzor has joined #dri-devel

14:02 jlawryno has joined #dri-devel

14:06 yuq825 has quit []

14:13 Leopold_ has quit []

14:13 gawin has joined #dri-devel

14:13 kts has joined #dri-devel

14:15 <gawin> seems debian enabled i915g, so it should be end of problems with amber

14:15 jlawryno has quit [Ping timeout: 480 seconds]

14:23 gawin has quit [Ping timeout: 480 seconds]

14:26 maxzor has quit [Ping timeout: 480 seconds]

14:26 fab has joined #dri-devel

14:37 jkrzyszt has quit [Remote host closed the connection]

14:45 jkrzyszt has joined #dri-devel

14:46 maxzor has joined #dri-devel

14:50 jkrzyszt has quit [Remote host closed the connection]

14:50 fab has quit [Quit: fab]

14:53 gawin has joined #dri-devel

14:53 Akari has joined #dri-devel

14:58 jewins has joined #dri-devel

15:03 Haaninjo has joined #dri-devel

15:12 sgruszka has quit [Remote host closed the connection]

15:13 jkrzyszt has joined #dri-devel

15:22 maxzor has quit [Remote host closed the connection]

15:22 maxzor has joined #dri-devel

15:27 pekkari has quit [Quit: Konversation terminated!]

15:30 fab has joined #dri-devel

15:37 pekkari has joined #dri-devel

15:46 maxzor has quit [Remote host closed the connection]

15:46 maxzor has joined #dri-devel

15:53 camus1 has quit [Ping timeout: 480 seconds]

15:57 jkrzyszt has quit [Remote host closed the connection]

16:04 <karolherbst> jekstrand: I think I'm getting more and more convinced that we should lower sampler/texture load_derefs not within nir_lower_io, but make frontends deal with that however they want. I just don't know how that's dealt with in vulkan though

16:07 <jenatali> At least for our Vulkan backend, we leave texture/sampler derefs in place

16:07 <karolherbst> jenatali: right.. but if you'd run lower_explicit_io with uniforms those would be lowered

16:08 <jenatali> Sure. But we don't

16:08 <karolherbst> yeah, but I do, just that radeonsi doesn't want that to happen :(

16:08 <jenatali> I don't remember why we leave them in place though. I feel like there was a good reason for that...

16:09 <jenatali> We lower them for GL and CL

16:09 <karolherbst> the thing is.. the current way of dealing witht his is to add another parameter to lower_explicit_io and it's quite annoying to do that :/

16:12 Duke`` has joined #dri-devel

16:13 <jenatali> Oh right we leave the derefs in place so we can chase to the variable to get the descriptor set index, which isn't a thing in GL/CL

16:15 <karolherbst> right... I'm mostly only annoyed by the fact that we don't have a var_sampler mode like we have for images, because that would make things easier

16:18 junaid has joined #dri-devel

16:23 tursulin has quit [Ping timeout: 480 seconds]

16:34 mbrost has joined #dri-devel

16:34 djbw has quit [Read error: Connection reset by peer]

16:41 djbw has joined #dri-devel

16:44 rgallaispou has quit [Read error: Connection reset by peer]

16:44 gawin has quit [Quit: Konversation terminated!]

16:49 MrCooper has quit [Quit: Leaving]

16:51 MrCooper has joined #dri-devel

16:52 eukara has quit []

16:52 <oneforall2> hmm mesa-22.3.0 -,32 isn't finding rust but mesa-22.2.4 is

16:53 <oneforall2> -,32/-m32

17:04 <kisak> mesa 22.2 finding rust? there are no rust dependencies in 22.2

17:12 Leopold_ has joined #dri-devel

17:25 MajorBiscuit has quit [Ping timeout: 480 seconds]

17:26 Guest1334 has quit [Remote host closed the connection]

17:30 <karolherbst> oneforall2: the meson cross file might have to be updated to reflect a 32 bit rust toolchain, not sure tho

17:34 <kisak> karolherbst: fwiw, it's very likely that 32 bit rusticl isn't going to happen in my PPA due to a lack of dependency package builds and Ubuntu's 32 bit restrictions.

17:39 lemonzest has quit [Quit: WeeChat 3.6]

17:40 ybogdano has joined #dri-devel

17:43 kts has quit [Quit: Leaving]

17:46 <mareko> Marge is chilling

17:49 <kisak> not a Marge problem? Marge is waiting on the results of https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/757970 -> window-vs2019 runner

17:49 <anholt> and swrast. couple of bad MRs taking 1.5 hours.

17:53 <anholt> https://gitlab.freedesktop.org/sergi/virglrenderer/-/issues/62

17:53 <jenatali> I suspect gstreamer is stealing the time from the Windows runners again. daniels ^^

17:55 <anholt> yeah, clogged with hour-long gstreamer jobs

17:56 <karolherbst> kisak: heh.. yeah well.. I don't see the use case for 32 bit CL anyway, so that's more or less fine. But what restrictions do you mean?

17:58 <anholt> as always, if you think marge is not doing things, check https://gitlab.freedesktop.org/users/marge-bot/activity and look at the pipeline in the MR linked from the last commit she pushed

18:05 <kisak> karolherbst: Ubuntu has a per-distro release i386 whitelist since Focal. There is no i386 bindgen or llvm-spirv-* related i386 builds allowed in their buildfarm.

18:06 <karolherbst> kisak: well, that sounds like something which could be changed, no?

18:07 <eric_engestrom> anholt: in 60a64f028d75ad6ca134 ("v3d: Use driconf to expose non-MSAA texture limits for Xorg.") you added the driconf to both v3d and vc4, but the code that this change applies to is only in v3d; did you mean to write the same 2048/7680 code in vc4, or was the driconf added to vc4 by mistake?

18:07 <eric_engestrom> (link to the commit, for easier look up: https://gitlab.freedesktop.org/mesa/mesa/-/commit/60a64f028d75ad6ca13468490adf1748cf9f1ec0)

18:08 <kisak> karolherbst: for primary packages with a good reason, maybe. PPAs have no valid say on the topic.

18:09 <anholt> eric_engestrom: don't remember for sure, you'd want to bring it up in Xorg and make sure that you still get the right driconf loaded if you drop the line

18:09 <karolherbst> well.. it's part of mesa 22.3, soo...

18:11 <eric_engestrom> anholt: there isn't a driconf file for vc4, or do you mean that v3d uses `pipe_vc4_create_screen()`?

18:11 <eric_engestrom> I stumbled upon this in my quest to understand what parts of vc4 are tangled in with v3d

18:19 <airlied> Lynne: doesnt appear the hw is that smart

18:19 <airlied> ffmpeg could just fill in zeros there if no pcm

18:19 <dcbaker> tjaalton: yes, I waas trying to get that out yesterday and then got sidetracked on other stuff

18:20 <Lynne> airlied: sounds like buggy hardware, so better let the driver take care of it

18:23 pekkari has quit [Quit: Konversation terminated!]

18:25 <tjaalton> dcbaker: ack, thanks

18:26 maxzor has quit [Remote host closed the connection]

18:26 maxzor has joined #dri-devel

18:27 <airlied> Lynne: i should check where vaapi covers it up

18:28 maxzor_ has joined #dri-devel

18:29 Leopold_ has quit [Remote host closed the connection]

18:29 Leopold_ has joined #dri-devel

18:34 maxzor has quit [Ping timeout: 480 seconds]

18:39 Akari has quit [Quit: segmentation fault (core dumped)]

18:42 <anholt> eric_engestrom: no, I mostly mean that loader and driconf stuff is all tremendously confusing and I'm not confident changing that without paging in a lot of context I don't have.

18:42 <eric_engestrom> haha that's fair

18:42 <anholt> it feels risky because X is going to be loading a vc4_dri.so since it's on the vc4 kms node

18:43 <anholt> that falls back to kmsro

18:43 <anholt> but the glue involved is just so many layers

18:43 <eric_engestrom> even if the driconf is useless, it's basically harmless, so no worries :)

18:44 <eric_engestrom> and yeah, I've been going through all these layers all day trying to understand how it fits

18:49 Leopold_ has quit [Remote host closed the connection]

18:49 lynxeye has quit [Quit: Leaving.]

18:50 Leopold_ has joined #dri-devel

18:51 mbrost has quit [Ping timeout: 480 seconds]

18:53 alanc has quit [Remote host closed the connection]

18:55 maxzor_ has quit [Ping timeout: 480 seconds]

19:02 ybogdano has quit [Quit: Ping timeout (120 seconds)]

19:10 ybogdano has joined #dri-devel

19:10 <Lynne> airlied: some help with figuring out the ref_slot is appreciated

19:10 <Lynne> to ease it somewhat, you should test with a file with no B-frames

19:11 <Lynne> on my system using -keyint_min 5 -g 5 with hevc_vaapi with amd generates a file like that

19:19 <airlied> Lynne: so you definitely got the slot index for the current image wrong

19:21 <airlied> i have a hacky ffmpeg patch

19:21 <airlied> https://paste.centos.org/view/raw/99660261

19:23 <Lynne> hmm, doesn't really fix it here

19:23 <Lynne> so the main frame is supposed to go last in the ref slots?

19:23 <airlied> nope it was just hacks

19:24 <airlied> im not sure

19:24 <airlied> just that i progrsma current index

19:24 <airlied> and in vaapi its the index after refs from what i can see

19:28 junaid has quit [Quit: leaving]

19:28 junaid has joined #dri-devel

19:29 iive has joined #dri-devel

19:37 tobiasjakobi has joined #dri-devel

19:38 tobiasjakobi has quit []

19:40 mhenning has joined #dri-devel

19:47 junaid has quit [Quit: leaving]

19:48 junaid has joined #dri-devel

19:50 Venemo_ is now known as Venemo

19:52 mbrost has joined #dri-devel

20:00 junaid has quit [Quit: leaving]

20:01 mbrost has quit [Ping timeout: 480 seconds]

20:02 <rodrigovivi> airlied: anything wrong with the drm-intel-next-fixes from last week? or that's queued to be pulled? I have 3 more fixes on top, but that could be an extra pr or even wait for next week... just checking...

20:02 mbrost has joined #dri-devel

20:02 junaid has joined #dri-devel

20:05 <DavidHeidelberg[m]> anholt: I squashed Nine tests in piglit and deqp-runner behind a PIGLIT_GALLIUM_NINE variable, is it way to go (before the integration into piglit happen, for which I'll have to find some time)

20:05 <DavidHeidelberg[m]> ? :) question mark

20:05 <Nyaaori> big endian be like https://gitlab.freedesktop.org/mesa/mesa/-/issues/7865

20:06 <Nyaaori> oh hi pepp

20:06 <Nyaaori> you're in here too

20:09 <anholt> DavidHeidelberg[m]: not clear what you mean

20:10 <DavidHeidelberg[m]> anholt: see this commit: https://gitlab.freedesktop.org/okias/mesa/-/commit/f035fb1edde56f07a5fe79f161bae9e956c09c83

20:11 junaid has quit [Ping timeout: 480 seconds]

20:11 <anholt> I will not be acking that. Just go get the tests into piglit.

20:12 <DavidHeidelberg[m]> anholt: ok, how to test Nine, when I currently cannot spend time on integration then? Standalone jobs?

20:12 <DavidHeidelberg[m]> or not to test it at all?

20:12 <anholt> if you're spending time on nine, spend time on getting the tests into piglit.

20:13 <anholt> I am so tired of deleting bad test scripts, that I will not be reviewing code for merge that introduces ad-hoc test scripts.

20:13 Jeremy_Rand_Talos_ has quit [Remote host closed the connection]

20:13 <DavidHeidelberg[m]> also the tests are synced with winehq code, so not sure how the integration will go with keeping upstream (wine) fixes

20:14 Jeremy_Rand_Talos_ has joined #dri-devel

20:18 <anholt> git shortlog --since="1 year ago" in the repo shows 5 commits from you, and maybe 1 is copying winehq code? So, it seems like you could have just copied equivalent code into the piglit tree?

20:21 <DavidHeidelberg[m]> anholt: when forking from Axel I just rebased the commit (since I was only user back then)

20:22 <DavidHeidelberg[m]> anholt: I'm not saying it's impossible, just it's working (not beatiful I agree), just having holiday today and never written piglit tests before, so I assume I would spend lot of time to polish it into usable piglit state

20:26 Daanct12 has joined #dri-devel

20:30 <Lynne> airlied: is the reference for the current frame meant to be in both the list of references and the ref_slot field?

20:31 <Lynne> I tried removing the current frame's ref, but things break badly(-er)

20:31 Danct12 has quit [Ping timeout: 480 seconds]

20:35 nchery has quit [Ping timeout: 480 seconds]

20:44 rahul_janga has joined #dri-devel

20:51 rahul_janga has quit []

20:52 <airlied> rodrigovivi: sorry just had a slow week, been on/off sick, should get to them soon

20:52 warpme____ has joined #dri-devel

20:54 fab has quit [Quit: fab]

20:54 rasterman has quit [Quit: Gettin' stinky!]

20:58 mbrost has quit [Ping timeout: 480 seconds]

21:01 mbrost has joined #dri-devel

21:02 nchery has joined #dri-devel

21:03 gawin has joined #dri-devel

21:06 <gawin> DavidHeidelberg[m]: wouldn't be easiest to fetch newest version from wine repo? or wine (itself as a runner) is too large for containers?

21:06 gouchi has joined #dri-devel

21:07 <DavidHeidelberg[m]> gawin: it has to be "adjusted" to fit into

21:08 <DavidHeidelberg[m]> gawin: and few jobs didn't compiled, so disabled. I opened piglit repo, found mine MR for -Werror, noticed that CI broke with recent tox... and.. at some point I'll look how to convert it

21:11 vyivel has quit [Remote host closed the connection]

21:11 bl4ckb0ne has quit [Remote host closed the connection]

21:11 emersion has quit [Remote host closed the connection]

21:12 bl4ckb0ne has joined #dri-devel

21:12 vyivel has joined #dri-devel

21:12 emersion has joined #dri-devel

21:22 tzimmermann has quit [Quit: Leaving]

21:25 maxzor has joined #dri-devel

21:35 zf_ has quit []

21:36 zf has joined #dri-devel

21:37 jkrzyszt has joined #dri-devel

21:38 <airlied> Lynne: I think I need to track where the vaapi values come from, there are some hw bits I'm not sure how to determine from the vk api

21:39 <DavidHeidelberg[m]> gawin: btw. there could be possibility that these tests will be not tied directly to wine anymore, but that's "maybe" in future

21:40 Duke`` has quit [Ping timeout: 480 seconds]

21:43 danvet has quit [Ping timeout: 480 seconds]

21:54 alanc has joined #dri-devel

21:58 apinheiro has joined #dri-devel

22:26 rmckeever has joined #dri-devel

22:30 jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]

22:30 jernej has joined #dri-devel

22:46 jkrzyszt has quit [Remote host closed the connection]

22:56 jkrzyszt has joined #dri-devel

22:58 digetx is now known as Guest1401

22:58 digetx has joined #dri-devel

23:01 Guest1401 has quit [Ping timeout: 480 seconds]

23:09 vliaskov has quit []

23:12 apinheiro has quit [Quit: Leaving]

23:13 jkrzyszt has quit [Ping timeout: 480 seconds]

23:34 dcz_ has quit [Ping timeout: 480 seconds]

23:47 sarnex has quit [Ping timeout: 480 seconds]

23:54 pcercuei has quit [Quit: dodo]

23:55 sarnex has joined #dri-devel

23:56 iive has quit [Quit: They came for me...]