ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
carbonfiber has quit [Quit: Connection closed for inactivity]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
mbrost_ has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst> jenatali: that's a long shot, but would you know what people could do in case a project got took over in a hostile way on github by a maintainer (by throwing out everybody else)?
<karolherbst> or whom to contact?
<jenatali> karolherbst: Are you able to elaborate on "a project"?
<jenatali> Oh this is about MS owning GitHub, not a MS-owned project
<karolherbst> yeah
<jenatali> No, GitHub is still pretty compartmentalized, I don't know anybody there
<karolherbst> ahh sad :(
<HdkR> karolherbst: They effectively own it at that point, no way to appeal as far as I know
<karolherbst> yeah.. which is an odd thing though
<karolherbst> so one could just sack a project and get away with it... sounds dangerous
<HdkR> That's what forking is for
<jenatali> I mean you'd have to have permissions in the first place to do that to the primary fork
<karolherbst> yeah welll...
<karolherbst> jenatali: yeah.. but sometimes a project is maintained by multiple people
<karolherbst> and sometimes one just had enough and hated all the others all along
<jenatali> Which means that either you're the original author, in which case copyright kinda says it's your right to do that, or else someone trusted that person enough
<jenatali> Yeah... that's fair
<karolherbst> just curious what would be the proper thing to do at this point
<psykose> if it's the one i'm thinking about the other people have probably messaged support and we'll see
<psykose> but a fork would be fine anyway
<karolherbst> yeah....
<psykose> is sad though
<karolherbst> very
<zmike> WHAT PROJECT IS IT
<karolherbst> PolyMC
<karolherbst> dude just kicked everybody and removed the CoC becase of "leftist extrimist" or some other crap reason
<zmike> aw
<jenatali> zmike: thank you
<zmike> jenatali: I am the id of #dri-devel
<jenatali> Wow, what even is this
<karolherbst> a minecraft launcher
<karolherbst> ahh yeah...
<karolherbst> "internet people"
zf has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
zf has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa> karolherbst: yo i heard you liked freenode
<karolherbst> rude
<alyssa> [witty reply]
<karolherbst> right....
<karolherbst> still though
<alyssa> [That was a shitpost about the polymc thing]
<alyssa> which I suppose is off topic here so zmike and I should get back to our regularly scheduled Mesa shitposts
<karolherbst> I might do more shitposting tomorrow, but this time it will hit somebody else
<alyssa> looking forward to ti
<alyssa> it
<psykose> dota ti? hell yeah
<bl4ckb0ne> get some rest psykose
pinchart1 has joined #dri-devel
<karolherbst> probably crunch some code tomorrow and post random stuff as usual
pinchart1 has left #dri-devel [#dri-devel]
* karolherbst looks at the pile of 100 commits to upstream
* karolherbst sighs
<alyssa> #define NVC797_SET_POINT_SIZE 0x1518
<alyssa> #define NVC797_SET_POINT_SPRITE 0x1520
<alyssa> oh SIZE vs SPRITE okay
pinchartl is now known as Guest3347
pinchartl has joined #dri-devel
<karolherbst> alyssa: what are you working on btw?
<alyssa> karolherbst: procrastinating
<karolherbst> I see
<alyssa> reading nv headers out of curiosity
<karolherbst> and are you successful?
<alyssa> they're certainly uhh something
<alyssa> #define NVC797_SET_ZCULL_STATS_ENABLE_TRUE 0x00000001
<alyssa> because what we really need is a bunch of #defines for true and false
<Sachiel> what's the counter for that one? DISABLE_TRUE or ENABLE_FALSE?
<jenatali> Hey you never know, maybe true is sometimes 2 instead of 1
<karolherbst> alyssa: well, it makes using them awesome
<karolherbst> we have a parser for those headers and everything
<karolherbst> so that's how we write command buffers :3
<alyssa> Oh that's awesome :-D
<karolherbst> yep
<karolherbst> that was like the goal on day one: make writing command buffers not painful
Guest3347 has quit [Ping timeout: 480 seconds]
<karolherbst> the ones with structs are actually bitfields
<karolherbst> like SET_ATTRIBUTE_DEFAULT e.g.
<karolherbst> and everything is validated before it gets send to the hardware
<karolherbst> even generated a dumper out of those headers. Having those really helps a lot
<alyssa> Yeah, I can imagine :-D
<alyssa> (I mean I don't have to imagine. GenXML for panfrost has been a massive boon of its own.)
<graphitemaster> <alyssa> because what we really need is a bunch of #defines for true and false
<graphitemaster> Don't forget FileNotFound (tralse)
Leopold_ has quit [Remote host closed the connection]
<graphitemaster> GPUs exclusively use three value logic. Take OpenGL for instance. TRUE, FALSE, DONT_CARE
<graphitemaster> TRUE, FALSE, NULL (SQL)
<graphitemaster> Logic gates be like 0, 1, X, Z - true, false, dont care, high impedance. Still waiting for GL/VK_HIGH_IMPEDANCE
<graphitemaster> Vulkan is low level right?
<graphitemaster> :trollface:
bencrus[m] has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2022-10-18 01:45:13)]
<jenatali> I'm legitimately annoyed that there's not an emoji for trollface yet
<HdkR> :smuggrin:
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
<karolherbst> ehhh.. I have to completely rework how zink handles shared and scratch mem :(
<karolherbst> oh well
<karolherbst> I'll do that tomorrow or so
<karolherbst> "Pass 2399 Fails 33 Crashes 10" sigh.. why couldn't it be one pass more :D
<psykose> then you'd get less customers
<karolherbst> ehh nir_lower_pack is broken :(
<karolherbst> oh well
<zackr> daniels: does mesa export that uber container to registry to be able to docker pull it directly?
lemonzest has quit [Quit: WeeChat 3.6]
mbrost_ has quit [Ping timeout: 480 seconds]
anshuma1 has joined #dri-devel
slattann has joined #dri-devel
mbrost_ has joined #dri-devel
rsalvaterra has quit [Quit: No Ping reply in 180 seconds.]
rsalvaterra has joined #dri-devel
Duke`` has joined #dri-devel
lyudess has joined #dri-devel
Lyude has quit [Read error: Connection reset by peer]
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #dri-devel
aravind has joined #dri-devel
rsalvaterra has quit [Quit: No Ping reply in 180 seconds.]
rsalvaterra has joined #dri-devel
fab has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
lemonzest has joined #dri-devel
tzimmermann has joined #dri-devel
kts has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
itoral has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
anshuma1 has quit []
<tjaalton> airlied: we're seeing llvmpipe crashing on armhf running mutter tests with mesa 22.2.1, and looks like there are two commits to llvmpipe in that release by you :)
<airlied> tjaalton: got a backtrace?
<airlied> if I had to guess it might be llvmpipe: bind sampler views/images properly. but not sure what could be causing it
<tjaalton> airlied: don't have a proper one, but the build-log is here and you can grep for LLVM ERROR https://launchpadlibrarian.net/629171689/buildlog_ubuntu-kinetic-armhf.mutter_43.0-1ubuntu3_BUILDING.txt.gz
<airlied> tjaalton: seems more liekly and llvm bug
<tjaalton> ack, thanks
<airlied> than something specific to 22.2.1 mesa
<airlied> like it might be a mesa bug but I doubt it's any of those commits
<airlied> more likely a newer llvm somewhere
<tjaalton> yeah we have 15.0.2
anshuma1 has joined #dri-devel
anshuma11 has joined #dri-devel
anshuma11 has quit []
ahajda__ has joined #dri-devel
anshuma11 has joined #dri-devel
anshuma1 has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
anshuma11 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
alanc has quit [Remote host closed the connection]
fab has quit [Quit: fab]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
alanc has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
<zzag> emersion: is it a driver bug if a drm connector is connected, i.e. DRM_MODE_CONNECTED, but it has 0 modes, i.e. count_modes == 0?
<marex> zzag: could it indicate the kernel could not find any suitable mode for the entire pipeline connected to that connector , e.g. due to bandwidth limitations ?
mvlad has joined #dri-devel
<MrCooper> zackr: beware that the default sorting shows the oldest tags first
<MrCooper> marex zzag: I think that could also happen if no EDID could be retrieved, e.g. due to a KVM switch or and old VGA monitor
kem has quit [Ping timeout: 480 seconds]
<zzag> MrCooper: how should the compositor handle such cases? try to use a custom mode, e.g. generated by libxcvt, and check whether it works using an atomic test only commit?
<MrCooper> good question :)
<marex> dont use the output ?
<marex> in case it has no mode, I wonder if there is a safe mode to set
<marex> in my case, I would consider e.g. two panels connected via different DSI links to the same scanout engine ; if the scanout engine has limited bandwidth, one panel might not have mode ... and what now ?
rasterman has joined #dri-devel
kem has joined #dri-devel
fab has joined #dri-devel
<emersion> MrCooper: i believe the kernel has a fallback mode list for missing EDID
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<daniels> zackr: yep, at the top of every job it prints ‘Running in registry.freedesktop.org/mesa/mesa/$container_id’ - that’s a public container URL you can pull when authed with a GitLab personal access token (go to user prefs) with read_registry scope
<daniels> why do you ask?
jkrzyszt has joined #dri-devel
Company has joined #dri-devel
danvet has joined #dri-devel
tursulin has joined #dri-devel
anshuma1 has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest3361
swalker__ has joined #dri-devel
Guest3361 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
vliaskov has joined #dri-devel
pendingchaos has quit [Read error: Connection reset by peer]
<jadahl> are there any drivers where there is any benefit of using GBM_BO_USE_CURSOR over plain dumb buffers?
<emersion> we're talking about small buffers so it doesn't really matter that much
<emersion> some drivers don't have any "special" cursor plane, they just have all planes the same
<emersion> so the cursor plane is just like any other plane
<emersion> and using GBM can unlock modifiers and larger buffers etc
MajorBiscuit has joined #dri-devel
pcercuei has joined #dri-devel
<jadahl> asking beacuse some drivers trip and fall if you're using USE_CURSOR instead of dumb buffers, so contemplating whether to just stop the usage of gbm for cursor buffers for all drivers
<emersion> which driver?
<emersion> we're unconditionally using GBM for cursors in wlroots
<jadahl> vc4
<emersion> i think the only place where it doesn't work is virtualbox
<jadahl> i see panfrost too in the proposed list
<emersion> vc4 works fine for me
<jadahl> it seems the issue that the two different gbm_bo's are getting the same fbid
<emersion> … wut
<emersion> that really shouldn't be possible
<jadahl> too bad I kind of bricked my arm laptop so can't debug myself :(
fahien has joined #dri-devel
<emersion> wlroots also doesn't use GBM_USE_CURSOR
<emersion> just plain GBM buffers
<emersion> with GBM_USE_LINEAR if there is no IN_FORMATS
<jadahl> mutter allocates with USE_CURSOR | USE_WRITE
<emersion> oh
<jadahl> then does gbm_bo_write()
<emersion> USE_WRITE will make GBM use dumb buffers
<emersion> so it's basically the same as doing that yourself
<jadahl> O_o
<emersion> instead, you can use gbm_bo_map() instead
<jadahl> why are they not getting the bug when using the "manual" dumb buffer helpers then?
<emersion> maybe GBM has a bug in that codepath, i don't know
<jadahl> perhaps
<pq> zzag, if there is no EDID and the connector is old VGA analog, I don't think even the kernel driver could detect whether a programmed video mode works or not. There is literally no feedback over the cable about what the monitor thinks about it.
<pq> zzag, such an old monitor could even be letting out smoke in that case.
<MrCooper> emersion jadahl: it's probably Mesa driver bugs, not properly de-duplicating BOs
<emersion> MrCooper: we're talking FBs here not BOs?
<emersion> are are we, jadahl?
<jadahl> emersion: different gbm_bo -> same fbid
<emersion> GBM BO handle, or KMS FB ID?
<jadahl> according to the debug output in a comment
<jadahl> what I see is a pointer address to a gbm_bo AFAICS
<emersion> okay, and a GEM handle?
<emersion> or the result of addfb2?
<jadahl> ah, same handle yes
<emersion> GEM handles are de-duplicated
<jadahl> from get_handle()
<emersion> okay, that can be normal then
<emersion> if it's the same underlying memory
<MrCooper> the Mesa driver needs to de-duplicate the BOs, or other things will break as well
<jadahl> MrCooper: you mean gbm_dri.c?
apinheiro has joined #dri-devel
<MrCooper> no, the driver
<MrCooper> only the driver can know whether or not it's actually the same kernel BO
<jadahl> MrCooper: isn't the handle what comes from DRM_IOCTL_MODE_CREATE_DUMB?
<MrCooper> GBM wouldn't use that?
<jadahl> yes
<jadahl> if (USE_WRITE) create_dumb() is what gbm_dri.c does
<MrCooper> and how is the other gbm_bo created which ends up returning the same GEM handle?
<jadahl> same way AFAIU
<MrCooper> sounds like a bug somewhere in or below create_dumb() then
<jadahl> create_dumb() isn't much...
<jadahl> can't see anything obvious wrong in how vc4 handles that ioctl either
<MrCooper> another possibility might be that the first dumb BO was actually already destroyed in the kernel, and the second one reused the same GEM handle
<jadahl> yea
<jadahl> but why would it?
<MrCooper> not sure offhand; might be possible to confirm via DRM debugging output though
<jadahl> one thing is that it goes b0 = ...; b1 = gbm_bo_create(); gbm_bo_destroy(0); b2 = gbm_bo_create();.. b1.handle and b2.handle are the same
<jadahl> maybe that triggers some bug
<jadahl> should open up my pinebook, flip some switches and see if I can get it to boot anything again...
djbw has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
fab has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
fab has joined #dri-devel
fahien1 has joined #dri-devel
Leopold_ has joined #dri-devel
<MrCooper> ishitatsuyuki: done
<ishitatsuyuki> thanks MrCooper
<MrCooper> no worries
fahien has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
ahajda_ has joined #dri-devel
ahajda__ has quit [Ping timeout: 480 seconds]
anshuma1 has quit []
ahajda_ has quit []
fahien1 has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
ahajda_ has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
<emersion> vsyrjala: have you seen my reply to the atomic async flip thread?
<vsyrjala> saw it. didn't have time to respond yet. recovering from flu...
<emersion> oh :S take care!
<emersion> no worries, just making sure it's not getting lost
devilhorns has quit []
fahien has joined #dri-devel
fahien has quit [Read error: Connection reset by peer]
itoral has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
linusw has joined #dri-devel
<linusw> who can rebase drm-misc-fixed to v6.1-rc1? I need to apply some fixes...
<mlankhorst> linusw: will do so
<linusw> mlankhorst: thanks a lot!
<mlankhorst> I think the last patches were sent as a pull request, so I need to check what happened first
<mlankhorst> mripard: ^?
kts has quit [Quit: Leaving]
<mripard> mlankhorst: I'm not sure what the question is?
slattann has quit [Quit: Leaving.]
slattann has joined #dri-devel
kts has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
kts has quit [Quit: Leaving]
sdutt has joined #dri-devel
<jfalempe> tzimmermann, may I push the "Fix PLL setup for G200_SE_A" to drm-misc-next ?
<tzimmermann> jfalempe, sure, go ahead
<jfalempe> ok thanks
<tzimmermann> if the buggy commit is in upstream, you can also use -misc-fixes
<tzimmermann> jfalempe ^
<jfalempe> so I should push to both drm-misc-next and drm-misc-fixes ?
<tzimmermann> jfalempe, 'git tag --contains 2dd040946ecf' says the bug is in v5.15. so the patch should go into drm-misc-fixes
<tzimmermann> jfalempe, do you absolutely need the patch in -misc-next now?
<jfalempe> no, misc-fixes should be enough
<tzimmermann> ok. we will sync trees at some later point and the bugfix will reach -misc-next as well
<jfalempe> ok, thanks, will push that to misc-fixes.
<tzimmermann> if a bugfix is immediately needed in both trees, one can merge into -misc-next and do 'dim cherry-pick' into -misc-fixes afterwards
<tzimmermann> it's like 'git cherry-pick' but with adding additional info
<jfalempe> ok
<jfalempe> tzimmermann, it doesn't apply to drm-misc-fixes, because it doesn't have the patch 877507bb954e "Provide per-device callbacks for PIXPLLC"
<jfalempe> but this is just moving code, so the same fix can be done in mgag200_pll.c
fahien has joined #dri-devel
<karolherbst> jekstrand: are there any rules in vulkan spirv we should be aware of in regards to OpBitcast? I was thinking of using that for shared/scratch mem as well, but zmike is under the impression we have to use aliased variables to deal with different bit_sizes
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
apinheiro has quit [Quit: Leaving]
kts has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<tzimmermann> jfalempe, then maybe commit it to drm-misc-next
<jfalempe> ok
fab has quit [Quit: fab]
<tzimmermann> from there, either cherry-pick with the necessary changes applied, or wait for backporters to add it to stable.
kts has quit [Quit: Leaving]
yuq825 has left #dri-devel [#dri-devel]
lygstate has joined #dri-devel
<lygstate> What's wrong with windows/ms farmer, it's very slow
alyssa has left #dri-devel [#dri-devel]
<jenatali> We're discussing in #_oftc_#freedesktop:matrix.org
<daniels> lygstate: it's 'just' oversubscribed
jewins has joined #dri-devel
fab has joined #dri-devel
kts has joined #dri-devel
mbrost has joined #dri-devel
siqueira has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
melissawen has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
isinyaaa has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
lemes has quit []
isinyaaa has joined #dri-devel
lemes has joined #dri-devel
melissawen has joined #dri-devel
siqueira has joined #dri-devel
heat has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<jekstrand> karolherbst: Yeah, we can't do that for shared/scratch.
<karolherbst> :'(
<karolherbst> well that's annoying
<jekstrand> karolherbst: For both, you need actual variables. There's no good way to do scratch today.
<karolherbst> but couldn't we just use uint8 vars and bitcast the offset?
<jekstrand> karolherbst: Some sort of scratch or local mem and ffma are the two extensions we actually need to get full OpenCL.
<karolherbst> yeah...
<karolherbst> getting very close btw: "Pass 2425 Fails 17 Crashes 0 Timeouts 0"
<jekstrand> karolherbst: Yeah, you can just use uint8 but the perf will suck
<jekstrand> karolherbst: \o/
<karolherbst> the issue is with overlapping accesses which I am sure is broken atm
<karolherbst> like you use shared as 16 bit, and later as 8 bit
<karolherbst> not sure there are many kernels just casting pointers like that, but...
<jekstrand> Yup. You'll have to do u8 and u8vec2
<jekstrand> And the u8vec2 won't be guaranteed to be atomic.
<karolherbst> uhhh... right...
pcercuei has quit [Read error: Connection reset by peer]
<karolherbst> jekstrand: another thing we hit yesterday was 1Dbuffer mem objects used as 1D images, which isn't explicit in the kernel
<karolherbst> apparently that's not that simple in vulkan
<jenatali> FWIW we use 32-bit vars for shared/scratch and adjust the indexing to match, as well as adding shifts for smaller types or splitting for larger types
<karolherbst> jenatali: sure, but then you kill atomicity of load/stores, no?
<karolherbst> though that might be fine if not actually doing atomics
<jenatali> IIRC atomicity is only required up to 32-bit?
pcercuei has joined #dri-devel
<karolherbst> I just remember we had some issues were this was causing problems
<karolherbst> but dunno
<karolherbst> maybe it's fine
<jenatali> Oh we have masked store intrinsics actually which turn the store into atomic and/or ops instead of a load/mask/store
<karolherbst> heh, figures
<jenatali> Only for shared of course, since scratch is per-thread anyway
<karolherbst> right
<karolherbst> but yeah doing non 32 bit as atomics fixes this problem indeed
<jenatali> Well, and global/ssbo since we also have 32-bit indexing there - though we can go down to 16-bit in some cases but 8-bit is nonexistent in DXIL
<karolherbst> yeah.. we don't have to use ssbos :)
<jenatali> Yeah even when we get a BDA equivalent, 8-bit loads and stores will be a separate thing
<karolherbst> huh
<karolherbst> weird
<karolherbst> why though?
* jenatali shrugs
<jenatali> You'd have to ask our compiler people, but it's on the roadmap I think
<karolherbst> ehh..
<karolherbst> in spir-v you just bitcast to the pointer type and you are done, no variables or other nonesense needed
<karolherbst> would be surprised if the bda equivalent you get would work differently
<karolherbst> but probably there are some weird reasons to do that differently
<jenatali> Yeah maybe it'll be GEP-based, I dunno
<jekstrand> karolherbst: Not sure what you mean
<karolherbst> jekstrand: not 100% sure either, but if you create an 1D image from a buffer apparently that matters for the spirv generated... though maybe it doesn't have to be? zmike should know about those details here
<zmike> what
<jenatali> karolherbst: CL has different types for 1D textures, and 1D texture-from-buffer
<karolherbst> zmike: the samplerless read stuff for 1d buffer which is still broken
<zmike> oh
<zmike> yeah I think that can't work without mutable descriptors
<karolherbst> jenatali: not in the kernel
<jenatali> Yeah, in the kernel?
<karolherbst> ohhh indeed... why didn't I see that before?
<jenatali> Yeah image1d_buffer_t is the buffer version
<karolherbst> okay.. then I was wrong and vbuffer is actually a vimage1Dbuffer thing...
<karolherbst> zmike: ^^
<zmike> so it's a rusticl bug?
<karolherbst> no, you got your vimage images vars, no?
<karolherbst> ehh
<karolherbst> vbuffer
<zmike> sometimes
<karolherbst> yeah, those are the 1D images from buffer things
<zmike> I'm using them
<karolherbst> okay
<zmike> but the type is still broken sometimes
<karolherbst> yeah...
<karolherbst> probably
<karolherbst> though I am sure I set up the image_view correctly
<karolherbst> maybe
<zmike> I'm still not clear on how this is supposed to work
<karolherbst> it should be the same as the stuff from GL though.. I might have messed something up
<karolherbst> but you'll get an image/sampler_view with a buffer format
<zmike> ok
<zmike> then that explains the fails in that test
<karolherbst> and in the shader you get the vbuffer image type
<karolherbst> but for GL it's the same I think
<zmike> current code should handle it correctly if that's true
<karolherbst> yeah.. I'll take a look and debug it, shouldn't be hard to figure out what's broken
<karolherbst> yeah.. target should be PIPE_BUFFER
<karolherbst> oh well...
<karolherbst> still figuring out why local_to_global is broken for long16 :(
<karolherbst> heh "SPIR-V module not valid: Having 16 components for TypeVector requires the Vector16 capability" oops
<zmike> 🚨
<karolherbst> though it does work for other vec16
<karolherbst> I think the more annoying part will be to make it work on nvidias blob vk driver as it doesn't yolo stuff like we do
<zmike> yes, that would require actual correct spirv
srslypascal has quit [Quit: Leaving]
<karolherbst> I am sure we have a pass to scalarize/split vec8 and vec16 thingies somewhere
luc4 has joined #dri-devel
srslypascal has joined #dri-devel
slattann has quit []
danilo has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
swalker__ has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
djbw has joined #dri-devel
srslypascal is now known as Guest3397
srslypascal has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
devilhorns has quit []
Guest3397 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<eric_engestrom> in shaderdb, does `shared program` mean something I don't know, or is that a typo for `shader program`?
heat has quit [Read error: No route to host]
heat has joined #dri-devel
<eric_engestrom> a quick blame shows it's been there since 2012 (aa4c13d372b9f0ada586e), so... someone would've spotted the typo by now, right?
carbonfiber has joined #dri-devel
<carbonfiber> On Ubuntu 22.04 running inside of VirtualBox, when trying to start Chrome from the command-line, I get the following error "dri3 extension not supported", this being despite using the "--disable-gpu" option. Is there a way to prevent this error?
fahien has quit []
<cwabbott> eric_engestrom: report.py counts LOST and GAINED programs which are only in the before or after, on intel this is usually due to gaining/losing SIMD16
<cwabbott> "shared" means it is in both before and after
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
<eric_engestrom> cwabbott: ah ok, makes sense; thanks!
* eric_engestrom wonders if there's another word that would be clearer
<jenatali> "common"?
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
lplc has quit [Ping timeout: 480 seconds]
<karolherbst> anholt: ahh, cool
alyssa has joined #dri-devel
<alyssa> kusma: Whoops
<zmike> oh neat
<alyssa> i wonder how many drivers we broke point sprites for :-D
aravind has quit [Ping timeout: 480 seconds]
Mangix has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Mangix has joined #dri-devel
gallo2 has quit []
gallo has joined #dri-devel
iive has joined #dri-devel
gallo has quit [Killed (NickServ (Too many failed password attempts.))]
gallo has joined #dri-devel
Haaninjo has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
gallo has quit []
gallo has joined #dri-devel
<dj-death> Is there something to do to be able to assign an issue to someone?
<dj-death> I can't assign to a colleague
<mareko> Mesa CI is stuck on the windows-vs2019 job, which is pending and not launching
<daniels> dj-death: they don’t show up in autocomplete unless they’re part of the project, but you can type in the full username and hit enter
<daniels> mattst88: known, being looked at
<mattst88> mareko: ^
<mareko> merges are timing out
<mareko> ok
<daniels> mareko: yeah, we know
<dj-death> daniels: not for assign apparently
<daniels> dj-death: hmm. does ‘/assign @foo’ work as a comment?
<dj-death> daniels: yep, thanks!
<daniels> nice
<daniels> (you can also do this for labels etc)
kem has quit [Ping timeout: 480 seconds]
<dj-death> daniels: that's nice
<kchibisov> Could someone enlighten me what should I reduce in the shader exactly to solve mesa-22.2.1/src/gallium/drivers/r300/compiler/r300_fragprog_emit.c::emit_alu(): Too many ALU instructions
<kchibisov> I have a feeling that not all operations count?
<anholt> kchibisov: seeing the shader might give a clue, but I'm not sure how to answer your question otherwise
kem has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<kchibisov> Though, it probably should be rewritten in some places anyway...
<anholt> at just 64 instructions for the first r300, eyeballing that shader it doesn't look like it'll fit. you'll probably have to have separate shaders per rectKind.
<kchibisov> So basically all math counts to that?
<anholt> yeah, but some math will be more than one op (pow is generally 3 ops on most hw)
<anholt> stuff like that
<anholt> negates are often free.
<kchibisov> Ah, so it's like that.
<kchibisov> cos also counts?
<anholt> hopefully the vectorizer is doing something nice for things like your distanceLeft/distanceRight pair, but there may be opportunities
<anholt> sin/cos are generally brutal on old hw.
<kchibisov> Is there some table for that?
<anholt> nope
<kchibisov> Well I have only one cos.
gouchi has joined #dri-devel
kts has quit [Quit: Leaving]
<kchibisov> anholt: I'd assume using multiple shaders will be better than having one giant shader?
<anholt> yeah, old hardware like that doesn't want an ubershader
<anholt> (especially when some of it, like i915, doesn't even have if statements!)
<kchibisov> And swapping shaders is pretty fast?
<kchibisov> Though, we would change shaders quite rare...
<anholt> swapping shaders per character would suck (this is a terminal emulator, yeah?). swapping shaders per style change, probably good.
<kchibisov> anholt: yeah, but we draw every rect on a screen with one draw call.
<kchibisov> I mean one draw call per style.
<anholt> btw, RADEON_DEBUG=vp,fp will give you output about the shader code generated.
<kchibisov> I mean I don't have r300 GPU.
<kchibisov> I just noticed the line from the bug report and since I can't debug anything myself decided to ask here.
<kchibisov> Thx for your help.
<anholt> if you want to debug, you could build mesa with drm-shim, paste your shader into a .shader_test file in https://github.com/freedesktop/mesa-shader-db and then LD_PRELOAD=<path-to-libradeon_noop_drm_shim.so> ./run <shader_test file>
mbrost has quit [Ping timeout: 480 seconds]
<kchibisov> That's interesting, thx.
* airlied should let zmike rebase to newer CTS before me
<zmike> 🤔?🤔?🤔?
<airlied> lvp boom boom
<zmike> ah
<zmike> I've been slacking on that lately
<airlied> bunch of crashes in common vk runtime pipeline code, had a simple "fix" but now up to 8k fails and counting
<airlied> dEQP-VK.pipeline.monolithic.stencil.*
<zmike> yikes
<airlied> it's one of those I suspect the test change might have been wrong, but I don't want to read the spec that closely :-P
<zmike> we have people to do that for us :p
<airlied> and I suspect causes all this failure
<zmike> no color attachments?
<airlied> might be a sideswipe between main and a merge from the branch
<airlied> ah well will dig a bit more later
chipxxx has quit [Ping timeout: 480 seconds]
alyssa has left #dri-devel [#dri-devel]
<Sachiel> that commit itself should be fine, the merge upwards broke all hell loose... you should be able to just add a .setDefaultColorBlendState() in there in the current main and it'll work
<Sachiel> airlied: ^
rasterman has quit [Quit: Gettin' stinky!]
Daanct12 has joined #dri-devel
mvlad has quit [Remote host closed the connection]
apinheiro has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
<airlied> Sachiel: ah yes I thought it was something like that
<airlied> Sachiel: thanks!
Haaninjo has quit [Quit: Ex-Chat]
gouchi has quit [Remote host closed the connection]
fab has quit [Quit: fab]
mbrost has joined #dri-devel
sdutt has quit []
ngcortes has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
genpaku has quit [Remote host closed the connection]
genpaku has joined #dri-devel
ahajda_ has quit [Ping timeout: 481 seconds]
luc4 has quit []
AndrewR has quit [Remote host closed the connection]
AndrewR has joined #dri-devel
pcercuei has quit [Quit: dodo]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<DemiMarie> Have the people working on virtio-gpu native contexts solved the uninitialized buffer problem?
<karolherbst> rusticl on zink on radv just being 7% slower than rocm is quite the surprise I had today... :D
<zmike> ACO TOO SLOW
<zmike> dschuermann: ^^^^ FIX
<karolherbst> I am already surprised it even validates :) we had 20% wrong pixels before but zmikes image fixes I think fixed that
<zmike> with enough hammers anything is possible
<karolherbst> one test is actually hitting the issue we have with private/shared memory betting split :(
<karolherbst> phhh
<karolherbst> I forgot to mention.. I still full flush after each kernel launch...
<zmike> smhhhhhhhhhhhhhhhhhhhhhh
<karolherbst> guess when I stop doing that I get a few percent more perf out of it or something :)
danvet has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
apinheiro has quit [Quit: Leaving]
vliaskov has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
Mangix has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Mangix has joined #dri-devel
iive has quit [Quit: They came for me...]
carbonfiber has quit [Quit: Connection closed for inactivity]
AndrewR has quit [Remote host closed the connection]
gawin has joined #dri-devel
<gawin> kchibisov: if the cell in "Shader opcodes" tab is empty, then the opcode must emulated by others and costs more than 1 instruction https://dri.freedesktop.org/wiki/R300ToDo/
<gawin> *probably costs more than 1 (some are trivial like mul)
Leopold has quit []
Dr_Who has quit [Read error: Connection reset by peer]