ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Namarrgon has quit [Quit: WeeChat 3.3]
Namarrgon has joined #dri-devel
<anholt> jekstrand: looks like we get a fixed-point x/y incorporating sample position. so we do fmul(i2f(xy), 1/16) to produce the float fragcoord
<anholt> for v3d you have a "get float x or y" instruction, and float z and w registers (and knowing if w is used other than by interp is useful)
<anholt> vc4 has integer x/y regs, unorm24 z reg you have to do math on, and a float w reg.
ella-0 has joined #dri-devel
pcercuei has quit [Quit: dodo]
mbrost has quit [Ping timeout: 480 seconds]
ella-0_ has quit [Ping timeout: 480 seconds]
<Kayden> jekstrand: adding that makes a lot of sense, frag_coord_uvec2 or frag_xy_uvec2 or frag_pos all seem fine to me
<Kayden> optionally splitting out z / w does also make a lot of sense...so many times you want xy, and the others you never care about
<Kayden> and it sounds like several drivers would be fine with that
<Kayden> being able to test for XY / Z / W separately via a BITSET_TEST(system_values_read, SYSTEM_VALUE_FRAG_COORD_XY) sounds pretty nice
tursulin has quit [Ping timeout: 480 seconds]
<Kayden> would save us from having to walk the program looking for load_frag_coord_xy/z/w intrinsics and call nir_ssa_def_components_read and | together any masks from each of them
<Kayden> though if we wanted to go that route, we could just do that in nir_shader_gather_info and have a frag_coord_components_mask of XYZW in shader_info.
<Kayden> but yeah, for us and it sounds like BCM, they're really different values, so just keeping them separate would be nicer
lemonzest1 has joined #dri-devel
lemonzest has quit [Read error: Connection reset by peer]
<Kayden> +1 for having sysvals for that that don't have magical implied semantics of forcing per-sample
<Kayden> honestly, I think we should not have any implied per-sample semantics in NIR shaders
<Kayden> we should probably just have the GLSL and SPIR-V front-ends handle that - if gl_FragCoord is read, then set a bit indicating we want it to be per-sample
<alyssa> jekstrand: 100% of what you said with frag coord uvec2 stuff also applies to mali
<alyssa> and i think agx
<alyssa> so that's two thumbs up from me
<alyssa> there's a preloaded register with uvec2(gl_FragCoord.xy) minus sample position
<alyssa> and if you really want fragz or fragw, you do a LD_VAR_SPECIAL.fragz or LD_VAR_SPECIAL.fragw
<alyssa> accessing a vec4 of gl_FragCoord is a lot of code
fxkamd has quit []
<alyssa> (the backend DCE cleans it all up of course)
<alyssa> I ... suspect gl_FragCoord + MSAA is broken on Panfrost as a result. I just hard code 0.5,0.5 ummmm
<HdkR> Oopsy :>
<alyssa> HdkR: Panfrost is conformant I said nothing about bugs ;)
<HdkR> Just means conformancy needs to test harder
mlankhorst has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<imirkin> is there anyone here who is or knows anyone who is well-versed in h264? i'm looking for someone who could answer some questions about how reference frames are referenced in the stream, and various decoder expectations.
rasterman has quit [Quit: Gettin' stinky!]
ybogdano has quit [Ping timeout: 480 seconds]
nchery is now known as Guest7264
nchery has joined #dri-devel
Guest7264 has quit [Ping timeout: 480 seconds]
<airlied> imirkin: I think it depends a lot more on the hw expectations
nchery has quit [Remote host closed the connection]
<airlied> at least between AMD and Intel the expectations are very different
<imirkin> airlied: well, what i know for sure is that i don't know anything about this
<imirkin> ;)
<airlied> I thought I had the intel model in my brain, but anv is proving I'm missing something
<imirkin> ideally the person would just have the perfect answer to the larger question of "it doesn't work, whyyyy", but i'd settle for just being better educated about it.
<anholt> mattst88: not sure how busy you are right now, but I was wondering if you'd be interested in picking up https://gitlab.freedesktop.org/mesa/mesa/-/issues/5700
<anholt> I've got some CI stuff I ought to get back to
<airlied> imirkin: is the nvidia hardware picture based? (/me assumes so since va is missing a lot of stuff for slices)
<airlied> https://www.vcodex.com/h264avc-picture-management/ is what I've read along with the spec a fair few times
<imirkin> airlied: can you make this a multiple choice question?
<airlied> but it's likely overkill if the hw does the slice decoding
<airlied> since a bunch of the details is hidden in slice headers, which on intel you have to decode on the CPU
<imirkin> airlied: vdpau has what nvidia wants
<imirkin> if it's not in vdpau, nvidia doesn't need it
<imirkin> that said, i think that the theory is that it doesn't handle all NAL types?
<imirkin> i have "NAL type 5" in my memory, but i have no further recollection of it
<airlied> I don't think that would be the problem you are facing here though
<imirkin> no, i don't think so either
<mattst88> anholt: definitely. I'll pick that up. thanks for letting me know
jhli has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
<alyssa> why all the sudden interest around video
<airlied> alyssa: why the lack of interest in video thus far? :-P
* airlied is mainly trying to get on top of vulkan video before it gets too far out of hand
gpuman has quit [Remote host closed the connection]
gpuman has joined #dri-devel
<alyssa> airlied: video is overrated
<alyssa> now if you'll excuse me I'm done with Mesa for the day
* alyssa opens netflix
<alyssa> ;-p
<airlied> alyssa: like I don't even video conference, not sure why I'm trying to fix it :-P
<alyssa> i don't play any 3d games or modeling or CAD or ... how did i get into mesa
<airlied> I used to play 3d games before I got into mesa
<HdkR> Mesa is the game
<airlied> we should get the person who recorded EA sports "it's in the game" to do a "Mesa is the game"
<Plagman> glxgears is basically factorio
<imirkin> alyssa: video was my first commit to mesa.
<HdkR> I need a vkgears to ensure I'm gaming efficiently
<imirkin> and the reason i got into nouveau way earlier was so i could get real-time decoding of ATSC streams :)
<imirkin> (not to be confused with ASTC...)
<alyssa> HdkR: mesa is indeed the game
<alyssa> zmike is beating all of us
<alyssa> imirkin: huh, nice :-)
<alyssa> so it was
<alyssa> alyssa@maud:~/mesa$ git log --author=Mirkin --oneline | tail -n 1
<alyssa> 4bc8e3c3e45 targets/xvmc-nouveau: add in missing nv30 lib
<imirkin> and now airlied has discovered (a part of) the reason why a particular video has been decoding wrong with the nouveau stuff across the various gens
<imirkin> so now i'm hoping i can extend that into an actual fix
idr has quit [Quit: Leaving]
<imirkin> alyssa: huh, so actually going back and reading some of those old commits, i found an itneresting reference to an unrelated problem which might actually solve this one.
<imirkin> right now we don't do as we were advised -- we don't set "tmp_idx" and "fifo_idx" to the same thing
<airlied> imirkin: okay yeah the fifo_idx/tmp_idx seems to be like the frame store idx on intel
<imirkin> (*that* problem with h264 hanging on the older chips was due to ... tiling parameters in the PTE's. sigh.)
boistordu_ex has quit [Ping timeout: 480 seconds]
<airlied> dang got anv fixed on part of the trailer, but broken in another :-(
gpuman_ has joined #dri-devel
lemonzest1 has quit []
gpuman has quit [Ping timeout: 480 seconds]
gpuman has joined #dri-devel
Danct12 has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
<imirkin> airlied: it's an evil video
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
haasn has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
Thymo has quit [Ping timeout: 480 seconds]
haasn has joined #dri-devel
Thymo has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
Duke`` has joined #dri-devel
mattrope has quit [Remote host closed the connection]
FireBurn has joined #dri-devel
<FireBurn> Hi, my dGPU (6800M) is no longer powering down when not in use, I'm not seeing anything suspicious in the dmesg, is there somewhere in /sys I can check what's happening? Is this likely to be a kernel issue or the upgrade to Xorg 21.1.1?
<jekstrand> alyssa: Awesome. I'll try to cook up some patches tomorrow for all that then. I think I'm going to go with frag_coord_xy_uvec2, frag_coord_z, and frag_coord_w. Or maybe drop the "_coord"
jewins has quit [Ping timeout: 480 seconds]
<imirkin> FireBurn: what does vgaswitcheroo say?
<FireBurn> I'm not seeing it
sdutt has quit [Read error: Connection reset by peer]
<FireBurn> It's definately enabled in my kernel
<imirkin> therein lies your problem then
<imirkin> no switcheroo = no poweroff
<FireBurn> What's it directory again?
<imirkin> /sys/kernel/debug/vgaswitcheroo iirc
<FireBurn> In my dmesg: vga_switcheroo: detected switching method \_SB_.PCI0.GP17.VGA_.ATPX handle
<FireBurn> But not seeing that directory
<FireBurn> Let me just boot into an old kernel brb
FireBurn has quit [Quit: Konversation terminated!]
FireBurn has joined #dri-devel
<FireBurn> It's happening with kernel 5.14.0 too
<FireBurn> Let me roll back my xorg-server version
<imirkin> ok. perhaps i'm not up on the latest in vgaswicheroo technology
<imirkin> nah, it's kernel
<imirkin> in theory this stuff should be managed by runtime pm
<FireBurn> Yeah I've been using switchable graphics since it was new
<FireBurn> I only noticed because there wasn't any lag doing DRI_PRIME=1 glxinfo
<FireBurn> I wonder if the logic that chooses BACO over PM is messed up
<imirkin> that logic is definitely messed up :) whether it's correct or not is another quesiton
<imirkin> airlied the expert on all this stuff. perhaps he's around
<FireBurn> Or maybe the audio driver holding the device open
<imirkin> yeah, that's another common one
<imirkin> you can dig around in /sys for the devices
<imirkin> and look at the runpm status of each subfunction
<imirkin> er, "function" rather
<airlied> FireBurn: maybe try with no desktop env running and see if you can figure out if it's powered off
<airlied> lspci might be slower if it has to poweron
<FireBurn> Will give that a go
<FireBurn> Any idea why the vgaswitcheroo isn't apearing in /sys
<FireBurn> Firing up chrome or smplayer used to fireup the card briefly
<FireBurn> Well it did on my old M395X
<FireBurn> brb
FireBurn has quit [Quit: Konversation terminated!]
FireBurn has joined #dri-devel
<FireBurn> As soon as I ran systemctl stop sddm, the card powered down
<FireBurn> [drm] free PSP TMR buffer
<FireBurn> You were right about lspci, runnign that I can see that card powerup and power down again
<FireBurn> [ 0.436836] vga_switcheroo: detected switching method \_SB_.PCI0.GP17.VGA_.ATPX handle
<FireBurn> [ 6.074529] snd_hda_intel 0000:03:00.1: Handle vga_switcheroo audio client
<FireBurn> [ 6.084119] snd_hda_intel 0000:08:00.1: Handle vga_switcheroo audio client
<FireBurn> Hmm I tried killing pipewire and I thnk it powered down and back up again
camus has quit [Remote host closed the connection]
<FireBurn> Yeah I think it's audio related
camus has joined #dri-devel
adjtm has quit [Remote host closed the connection]
FireBurn has quit [Quit: Konversation terminated!]
adjtm has joined #dri-devel
itoral has joined #dri-devel
FireBurn has joined #dri-devel
<FireBurn> Bingo disabling SND_HDA_INTEL makes the GPU power down and up correctly based on DRI_PRIME
<FireBurn> Should I file the bug against ALSA?
<vsyrjala> does disabling the hda silent stream stuff change anything?
<FireBurn> It wasn't enabled
<FireBurn> # CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM is not set
lemonzest has quit [Quit: WeeChat 3.3]
lemonzest has joined #dri-devel
<FireBurn> I'm also a bit confused whether or not I need the SND_SOC_AMD stuff or not
danvet has joined #dri-devel
mszyprow_ has joined #dri-devel
JoseExposito has joined #dri-devel
tzimmermann has joined #dri-devel
pnowack has joined #dri-devel
mlankhorst has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
ella-0 has quit [Ping timeout: 480 seconds]
mbrost has quit [Read error: Connection reset by peer]
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
jkrzyszt has joined #dri-devel
JoseExposito has joined #dri-devel
loki_val has joined #dri-devel
crabbedhaloablut has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
tursulin has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
JoseExposito has quit []
adjtm is now known as Guest7293
adjtm has joined #dri-devel
Guest7293 has quit [Remote host closed the connection]
JoseExposito has joined #dri-devel
agd5f has quit [Remote host closed the connection]
JoseExposito has quit [Quit: JoseExposito]
JohnnyonFlame has joined #dri-devel
JoseExposito has joined #dri-devel
pcercuei has joined #dri-devel
Company has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
JoseExposito has quit [Remote host closed the connection]
JoseExposito has joined #dri-devel
JoseExposito has quit [Remote host closed the connection]
JoseExposito has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
Duke`` has quit [Remote host closed the connection]
i-garrison has quit []
i-garrison has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
itoral has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.3]
itoral has joined #dri-devel
aravind has joined #dri-devel
pendingchaos_ is now known as pendingchaos
lemonzest has joined #dri-devel
mclasen has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
gawin has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
JohnnyonFlame has quit [Remote host closed the connection]
yk has joined #dri-devel
itoral has quit []
aravind has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
Duke`` has joined #dri-devel
<alyssa> jekstrand: See bi_emit_load_frag_coord in src/panfrost/bifrost/bifrost_compile.c btw
<alyssa> oh right, there was the other fun bit with bifrost
<alyssa> frag_coord_xy_uvec2 is 16-bit ints on bifrost
<alyssa> so u16_to_f32 is the conversion used
yk has quit [Remote host closed the connection]
sarnex has joined #dri-devel
<Ristovski> FireBurn: Do you have a program thats polling for the GPU temperature?
<Ristovski> There was a change in ~5.14-ish that made amdgpu wake the GPU up from suspend when you query for its temperature via hwmon, whereas before it would return N/A or something.
<Ristovski> oh nvm I missed the part where its an audio issue, disregard
agd5f has joined #dri-devel
<bbrezillon> jekstrand: any remaining blockers on !12031 (I'd like to rebase !12210 on top of it and do as you suggested in your review)? I can help with the rebase if needed
sdutt has joined #dri-devel
<FireBurn> Ristovski, thanks for replying, no I don't use anything to monitor temps
<FireBurn> I'm still not sure whether I should be reporting this against amdgpu or alsa
yk has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.3]
jewins has joined #dri-devel
lemonzest has joined #dri-devel
mattrope has joined #dri-devel
FireBurnUK has joined #dri-devel
FireBurn has quit [Read error: Connection reset by peer]
FireBurn has joined #dri-devel
FireBurnUK has quit [Read error: Connection reset by peer]
FireBurn has quit []
JohnnyonFlame has joined #dri-devel
<jekstrand> alyssa: frag_coord_xy_uvec2 is actually 16-bit for us as well, IIRC.
<jekstrand> bbrezillon: I'll take a look in a minute
<jekstrand> alyssa: Yup, UW type
<bbrezillon> jekstrand: thanks!
<jekstrand> bbrezillon: I think I was hoping for more than an ACK but given that no one seems to care, I'll rebase and merge today.
camus1 has joined #dri-devel
<jekstrand> Looks like ir3 wants it split as well, probably
camus has quit [Ping timeout: 480 seconds]
mort_ has joined #dri-devel
<mort_> stupid question maybe, but: what's up with <EGL/eglmesaext.h>? I currently can't compile wlroots because it's missing, but it also doesn't really seem to be a thing anymore?
FireBurn has joined #dri-devel
<FireBurn> So I turn on debugging and the issue goes away
gawin has quit [Ping timeout: 480 seconds]
<FireBurn> https://dpaste.com/9GTTDP9V5 is the diff between the kernel configs
Haaninjo has joined #dri-devel
<FireBurn> I'm not sure what soundwire is or why it was enabled either
<jekstrand> bbrezillon: Ugh... This x11 shm stuff is plumbed through really weird and it's conflicting. :-/
<bbrezillon> jekstrand: any way I can help?
<jekstrand> At the moment, no. After a bit, maybe revew a couple of new patches.
<jekstrand> I've got to figure out how I want to plumb this.
* jekstrand really doesn't like this MIT-SHM path
<emersion> mort_: some exts were missing from the khronos header at some point, so the mesa one was required
<mort_> awesome
<emersion> it has been fixed now, the khronos header has everything now
<mort_> yea not on old systems
<mort_> ik, just update
<alyssa> jekstrand: without MIT-SHM, x11 swrast perf is garbage
<alyssa> speaking from experience, sadly.
<jekstrand> Oh, I know
<jekstrand> I don't mind using MIT-SHM, I just don't like the way it's plumbed
<alyssa> ack
<jekstrand> Or the fact that it's plumbed entirely differently from wl_shm
<MrCooper> emersion: FWIW, journalctl --dmesg works for me as normal user even if dmesg itself doesn't
<MrCooper> it should also have everything even if the buffer has wrapped around
<emersion> ah, interesting
<emersion> probably one more systemd magic thing happening if the user is physically logged in
camus has joined #dri-devel
alyssa has left #dri-devel [university awaits]
<MrCooper> not sure it's related to being physically logged in, just journald gathering dmesg and making it available to users with sufficient credentials
camus1 has quit [Remote host closed the connection]
Company has quit [Read error: No route to host]
<emersion> indeed, it works even if i'm not physically logged in
Company has joined #dri-devel
<emersion> (things like `systemctl restart` use physically logged in checks)
<MrCooper> interesting
<emersion> (also systemd changes file permissions to /dev/dri/* and other things depending on that)
Tooniis[m] has quit []
Tooniis[m] has joined #dri-devel
Tooniis[m] has quit []
Tooniis[m] has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
<pepp> jekstrand: could you take a look at !13959 please (vulkan wsi changes)?
<FireBurn> [ 2.710649] amdgpu 0000:03:00.0: amdgpu: smu driver if version = 0x0000000e, smu fw if version = 0x00000012, smu fw version = 0x00412e00 (65.46.0)
<FireBurn> [ 2.710654] amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched
<FireBurn> The versions are totally different, is that a bug/typo in the code
<jekstrand> bbrezillon: I think I've got it rebased now. Running in CI.
<jekstrand> pepp: What's the point behind creating the PRIME buffer on the display GPU?
<jekstrand> If they're different GPUs, it should end up in system memory either way
<bbrezillon> jekstrand: I'll test it tomorrow. Thanks again for taking care of that
<pepp> jekstrand: to avoid an extra-copy
<jekstrand> pepp: Who's doing that copy?
<pepp> jekstrand: X
<jekstrand> Oh... So X is detecting that it's imported across GPUs and doing a copy itself?
<MrCooper> it can't detect that; presumably it's about direct scanout?
<pepp> jekstrand: eg X can't scanout from the imported buffer so it has to do a copy
<jekstrand> But who tells it that it can't scanout? Does i915 just reject it or something?
<jekstrand> danvet: ^^
rgallaispou has quit [Read error: Connection reset by peer]
<emersion> yea, it'll just try to drmModeAddFB2
<MrCooper> the display GPU's KMS driver would
<emersion> and this would fail for a scan-out-incompatible buffer
<MrCooper> AFAIK this is currently only used if both sides are radeonsi
<MrCooper> (this = the path where the PRIME buffer is allocated on the display GPU)
fxkamd has joined #dri-devel
<jekstrand> MrCooper: Sure, the path currently only works if they're both AMD. I think it also only really works if they're basically the same GPU, though I may be reading that a bit wrong.
<jekstrand> But there's no reason to restrict it to both AMD
<MrCooper> don't think same GPU is a requirement
<jekstrand> MrCooper: NVM, I read it wrong
<MrCooper> really it would just need to check that the display GPU is using a Mesa driver as well
sdutt has quit []
sdutt has joined #dri-devel
<MrCooper> though if this were done with an Intel display GPU and an AMD render one, the buffer allocated by the former might not be usable by the latter (since Intel GPUs tend to have much laxer requirements for pitch alignment)?
The_Company has joined #dri-devel
gouchi has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
<jekstrand> MrCooper: The pitch alignment is taken care of by the core Vulkan WSI code and it's 256B.
<jekstrand> which, I believe, is good enough for everyone.
<MrCooper> right, so that would only be an issue for GL then
<jekstrand> yup
<jekstrand> For Vulkan, what we actually create for the prime image is a VkBuffer and we use CopyImageToBuffer with an explicit stride like you would use for a texture download.
<jekstrand> Are the major/minor numbers enough to uniquely identify a DRM device?
<emersion> the dev_t is enough
<emersion> major/minor is used in vulkan as a workaround for getting fixed size struct fields
<jenatali> Anyone willing to ack https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13902? I've got a review but I'd like at least an ack from a core maintainer before merging a CI change like that
<jekstrand> emersion: Ok, cool.
<jekstrand> That still leaves a pretty annoying problem: The WSI code lives per-driver and can't see any other physical devices in the system.
<emersion> why do you need to know about other physical devices?
<jekstrand> If it were a proper layer, that wouldn't be a problem
<jekstrand> emersion: So that AMD can allocate on Intel or vice versa
<emersion> why is this necessary?
<jekstrand> emersion: For the PRIME blit case so that you can get scanout from the PRIME buffer. See above conversation.
<emersion> please don't do kmsro levels of magic
<emersion> this is for the display WSI right?
<jekstrand> X
<jekstrand> Or Wayland, I guess
<emersion> hm
<jekstrand> Right now, KMS will fail the drmAddFB2 if the buffer is on the wrong GPU.
<jekstrand> Though I don't really see why, TBH.
<emersion> desktop GPUs can't scanout foreign buffers in general
<jekstrand> It does have to force it to be migrated to system memory but, from there, it should be able to scan out, I'd think.
<jekstrand> emersion: This is for the dGPU -> iGPU case
<emersion> no, it has to be local
<emersion> ah, ok
<jekstrand> On integrated, it shouldn't matter where it comes from.
<emersion> i think that's wired up for amd dGPU → amd iGPU
<jekstrand> Apart from caching quirks
jhli has joined #dri-devel
<HdkR> Hopefully CXL memory devices will save us from our sins. Scanout from CXL visible :D
<MrCooper> see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10595#note_904255 , the motivation for this was P2P DMA, in which case the render GPU can directly access the buffer in the display GPU's VRAM
ngcortes has joined #dri-devel
adjtm has quit [Quit: Leaving]
<ajax> datura:~/git/mesa% relinfo build/src/gallium/targets/dri/libgallium_dri.so
<ajax> build/src/gallium/targets/dri/libgallium_dri.so: 24725 relocations, 24185 relative, 741 PLT entries, 5 for local syms, 0 users
ybogdano has joined #dri-devel
xorton has joined #dri-devel
mbrost has joined #dri-devel
gpuman_ has joined #dri-devel
March-123 has joined #dri-devel
<jekstrand> jenatali: Where did we land on libclc, magic builtins and fma?
<jenatali> It's a driver option whether fma32 should be lowered using libclc or if it should map to the nir opcode
gpuman has quit [Ping timeout: 480 seconds]
mszyprow_ has quit [Ping timeout: 480 seconds]
<jekstrand> jenatali: Does CLOn12 use the clc version?
<jenatali> It does
<jekstrand> No nice fma precision requirements?
<jenatali> The CL CTS requires much tighter precision requirements than D3D does
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
craftyguy_ has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<xorton> Hi. I'm trying to implement a test requested in this issue: https://bugs.freedesktop.org/show_bug.cgi?id=107073 Can you suggest any decent tutorials on DRI, or some examples?
craftyguy has quit [Ping timeout: 480 seconds]
craftyguy_ is now known as craftyguy
milkylainen has quit [Quit: Connection closed]
ybogdano has quit [Ping timeout: 480 seconds]
milkylainen has joined #dri-devel
xorton has quit [Remote host closed the connection]
idr has joined #dri-devel
ybogdano has joined #dri-devel
boistordu has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
* ajax getting itchy to see classic gone
ybogdano has quit [Ping timeout: 480 seconds]
* jekstrand too
<jekstrand> cmarcelo: Do you remember if we do anything clever in spirv_to_nir to only add builtin variables for the entrypoint specified?
<jekstrand> I'm trying to figure out if we can reliably detect gl_SampleID and gl_SamplePos before we've inlined functions and done dead-code.
<jekstrand> Looking at spirv_to_nir, it seems we never emit dead functions.
gpuman_ has joined #dri-devel
March-123 has quit [Ping timeout: 480 seconds]
gpuman has quit [Ping timeout: 480 seconds]
<jekstrand> THis is fun:
<jekstrand> If a fragment shader entry point’s interface includes an input variable decorated with SamplePosition, Sample Shading is considered enabled with a minSampleShading value of 1.0.
<jekstrand> I think that technically means we're supposed to sample-shade even if you never use it.
jewins1 has joined #dri-devel
xorton has joined #dri-devel
<idr> I seem to recall there being a bunch of twitchy issues there... we may very well do it wrong.
<jekstrand> Yeah, pretty sure we do
<jekstrand> Not sure if we get it right for GL or not. I'll look after I'm done fixing Vulkan.
<idr> I recall it being a thing that was discussed to death in GL meetings years ago.
xorton has quit [Remote host closed the connection]
<jekstrand> I could believe that
<airlied> is there any CTS tests or ways to test it at all?
<jekstrand> The way Vulkan specs it, yes.
<jekstrand> I think the Vulkan spec implies that you end up with per-sample interpolation too
jewins has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
<cmarcelo> jekstrand: I don't think we have anything special for that. so, for those cases we have different semantics between "variable exists but not used" vs. "variable not exists"?
<jenatali> Sounds like the special case needs to be "variable declared in entrypoint's interface" vs not
<jekstrand> cmarcelo: We track the stuff that's part of the entrypoint interface. I've got a patch now, I think.
adjtm has joined #dri-devel
<cmarcelo> jekstrand: yes, we do track that.
<cmarcelo> ok. please tag me on that one
Duke`` has quit [Ping timeout: 480 seconds]
<cmarcelo> jenatali: yeah, makes more sense
ngcortes has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
Haaninjo has quit [Quit: Ex-Chat]
jkrzyszt has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
pcercuei has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
March-123 has joined #dri-devel
eukara_ has joined #dri-devel
eukara has quit [Read error: Connection reset by peer]
eukara_ has quit [Ping timeout: 480 seconds]
<jekstrand> Kayden: Who adds sample_pos to frag_coord in iris?
nchery is now known as Guest7335
nchery has joined #dri-devel
Guest7335 has quit [Ping timeout: 480 seconds]
<jekstrand> Bah... Even though it's all UW, our driver casts to float. :-(
<jekstrand> in the back-end
<Kayden> jekstrand: nir_lower_wpos_ytransform.c I believe
<jekstrand> Kayden: I looked in there and couldn't find it. :-/
* jekstrand hates the magic PIXEL instructions...
<Kayden> this is not really ringing a bell :(
<jekstrand> I'm also very confused by the Gen12.5+ pixel setup
<jekstrand> I just want gl_FragCoord.xy as integers.... is that really so hard?
<Kayden> I remember being pretty confused by it for a while as well
<jekstrand> We're doing an `ADD(32) int_pixel_x<1> stuff, stuff`, then maybe another ADD and then we do a strided MOV from int_pixel_x, throwing away half the calculations.
March-123 has quit [Ping timeout: 480 seconds]
<Kayden> a2572a9da49561af2d8dafce44bbb50c80505531 says regioning restrictions
<idr> mareko: I'd like to merge !13095. Could I get an Acked-by or something for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13095/diffs?commit_id=84dd3bded259806f5af847085487fad707115097 ?
<jekstrand> Kayden: Yeah, that explains the two adds instead of one weird stride add. It doesn't explain the weird destination stuff.
<jekstrand> Maybe curro remembers?
<jekstrand> In any case, thanks to all these weird strided MOVs, I'm not sure I can do the pixel_xy_int system value like I wanted. :-(
<jekstrand> Not without adding an instruction to BDW+/SIMD8
<dj-death> I thought I wrote some nice comments to explain the pixel setup stuff
<jekstrand> dj-death: You did, but not for 12.5
<dj-death> TLDR; yes, half is discarded
<jekstrand> But why bother computing that half?
<jekstrand> dj-death: Also, I'm confused as to how SIMD16 works with coarse
<jekstrand> I shouldn't be... I reviewed it after all
<jekstrand> Oh, because we never take that path on Gen < 8
<jekstrand> Ok, that's fine
<dj-death> I understood that code and wrote my CPS code
<jekstrand> dj-death: Ah, looking in the wrong place
<jekstrand> dj-death: And then forgot? :P
<dj-death> then forgot about it and it took me 4hours to remember
<jekstrand> hehe
<dj-death> then I wrote that comment
FireBurn has quit [Remote host closed the connection]
FireBurn has joined #dri-devel
<jekstrand> It's almost 6:00 PM here. I'm not going to try to grok this code tonight.
<jekstrand> suffice it to say that I think my grand plan of doing the i2f in NIR is toast.
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]