ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
anholt has quit [Ping timeout: 480 seconds]
stuarts has quit []
zzoon has joined #dri-devel
anholt has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
shsharma has joined #dri-devel
shsharma__ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
naive CI question
<alyssa>
why is debian-vulkan a separate job?
mohamexiety has quit []
<alyssa>
don't the regular jobs also build vulkan?
shsharma_ has joined #dri-devel
rosefromthedead has quit [Remote host closed the connection]
DavidHeidelberg[m] has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<alyssa>
i'm not saying it should be changed I just don't understand what it's testing
shsharma has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
YuGiOhJCJ has joined #dri-devel
minecrell has quit [Remote host closed the connection]
minecrell has joined #dri-devel
fxkamd has quit []
kzd_ has quit []
columbarius has joined #dri-devel
kzd has joined #dri-devel
co1umbarius has quit [Ping timeout: 481 seconds]
JohnnyonF has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
Danct12 has joined #dri-devel
yuq825 has joined #dri-devel
mbrost has joined #dri-devel
lemonzest has joined #dri-devel
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
mbrost has quit [Remote host closed the connection]
alpalcone has joined #dri-devel
lplc has quit [Ping timeout: 480 seconds]
<Venemo>
I think this is an interesting issue, but not sure how to label it as it affects many different parts of mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4742 it seems that it fell through the cracks due to not being labeled
bmodem has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
lemonzest has quit [Quit: WeeChat 3.6]
bluetail has quit [Ping timeout: 480 seconds]
<airlied>
Venemo: probably one to throw at the mailing list instead, or add all the tags to
<airlied>
that really need some sort of toplevel owner to make it happen
Zopolis4 has joined #dri-devel
srslypascal is now known as Guest7909
srslypascal has joined #dri-devel
Guest7909 has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
lemonzest has joined #dri-devel
lemonzest has quit []
kzd has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<Venemo>
airlied: yes I agree
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
kts has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
boqun has joined #dri-devel
bgs has joined #dri-devel
Company has quit [Quit: Leaving]
sewn has joined #dri-devel
<mupuf>
anholt: thanks for letting me know! I'm on it!
<mupuf>
seems like the MR to disable it did not land
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
bluetail has joined #dri-devel
boqun has quit [Ping timeout: 480 seconds]
boqun has joined #dri-devel
<mupuf>
it's back up, and I am combing the logs to see what happened
<mupuf>
but I would understand if you guys would rather wait
<mupuf>
CI is already flaky enough
boqun has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
fab has joined #dri-devel
boqun has joined #dri-devel
chip_x has joined #dri-devel
danvet has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
chipxxx has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
Shibe has quit [Remote host closed the connection]
chip_x has quit [Remote host closed the connection]
fab has joined #dri-devel
frieder has joined #dri-devel
boqun has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
boqun has joined #dri-devel
Haaninjo has joined #dri-devel
boqun has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
MajorBiscuit has joined #dri-devel
pcercuei has joined #dri-devel
Zopolis4 has joined #dri-devel
boqun has joined #dri-devel
jfalempe has quit [Remote host closed the connection]
jfalempe has joined #dri-devel
tursulin has joined #dri-devel
Major_Biscuit has joined #dri-devel
boqun has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
boqun has joined #dri-devel
boqun has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
boqun has joined #dri-devel
rosefromthedead has joined #dri-devel
boqun has quit [Ping timeout: 480 seconds]
frytaped[m] has quit []
Jean[m]1 has quit []
ralf1307[theythem][m] has quit []
hasebastian[m] has quit []
boqun has joined #dri-devel
<javierm>
airlied, jani, tzimmermann: I was reading the thread about firware versions and initrd and wondered if there's really a need to have a native DRM driver in the initrd
<javierm>
if is only to add your LUKS password or troubleshoot the system if fails to mount the rootfs partition, etc then simpledrm should be enough I believe
<javierm>
airlied, jani, tzimmermann: didn't answer in the thread to not derail the current conversation but maybe avoiding to add the DRM drivers (and related firmware) could be a solution for this as well
<tzimmermann>
javierm, i'm not in the business of building initrds, but that would be my take on this as well. having native drm drivers in the initrd is a nice-to-have. if one of the them interferes, it has to remain on the root partion
<javierm>
tzimmermann: I've no business in building initrds either :) but with my fedora distro developer hat, I believe that would be the best approach
<javierm>
specially since huge initrds are big problem, for example for folks doing booting over the network (PXE and HTTP boot) and so forth
boqun has quit [Ping timeout: 480 seconds]
boqun has joined #dri-devel
rszwicht has joined #dri-devel
<q4a>
Hi. Simple questions: is it possible to use some gallium drivers (like Panfrost, Nine) on Android? Maybe someone can add a description of how Mesa is limited on Android to docs like https://docs.mesa3d.org/android.html ?
robertfoss[m] has quit []
r[m] has quit []
halfline[m] has quit []
tleydxdy has quit []
sjfricke[m] has quit []
kunal_1072002[m] has quit []
RSpliet has quit [Quit: Bye bye man, bye bye]
boqun has quit [Ping timeout: 480 seconds]
RSpliet has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
rszwicht has quit []
jdavies has joined #dri-devel
jdavies has quit []
boqun has joined #dri-devel
fab has quit [Read error: Connection reset by peer]
rszwicht has joined #dri-devel
fab has joined #dri-devel
<airlied>
javierm: I talked to karolherbst about it, he said for a lot of laptops simpledrm isn't enough
<airlied>
esp boot with lid closed you get nothing until a drm driver loads often
chipxxx has joined #dri-devel
<javierm>
airlied: ah, that's a good point
boqun has quit [Ping timeout: 480 seconds]
boqun has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
skinkie has joined #dri-devel
<skinkie>
I have the recurring issue where video= (or even user space) just does not take a specific mode, likely because the name of the mode is equal to another mode.
<skinkie>
And the difference here is the framerate, so 1920x1080@50e becomes 1920x1080@60. While for example xrandr would be perfectly capable to switch it to 50p. Now also see the variant where 50 becomes 50i, without actually specifying interlacing.
boqun has quit [Ping timeout: 480 seconds]
headless has joined #dri-devel
devilhorns has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
kts has joined #dri-devel
boqun has joined #dri-devel
kts has quit []
madhavpcm has joined #dri-devel
boqun has quit [Ping timeout: 480 seconds]
smiles has quit [Read error: Connection reset by peer]
rszwicht has quit [Read error: Connection reset by peer]
aravind has quit [Ping timeout: 480 seconds]
<madhavpcm>
Great! Im interested to work in the GUI projects namely,adriconf enhancements and Vulkan GPU preference tool
<madhavpcm>
I have some experience with the tools mentioned, Can anyone help me with other prerequisites if any?
boqun has quit [Ping timeout: 480 seconds]
<madhavpcm>
I also noticed a patch was to be submitted and it would be great if I could get some details on that :)
kawagucci has joined #dri-devel
kawagucci has left #dri-devel [#dri-devel]
boqun has joined #dri-devel
madhavpcm has left #dri-devel [Leaving]
madhavpcm has joined #dri-devel
boqun has quit [Ping timeout: 480 seconds]
chip_x has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
chip_x has quit [Max SendQ exceeded]
chip_x has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
boqun has joined #dri-devel
chipxxx has joined #dri-devel
chipxxx has quit [Max SendQ exceeded]
madhavpcm has quit [Remote host closed the connection]
chipxxx has joined #dri-devel
chip_x has quit [Ping timeout: 480 seconds]
boqun has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
boqun has joined #dri-devel
<zmike>
mareko: I've got cts changes up for 2/3 the issues, but I'm still missing some context for the KHR-GL46.gpu_shader_fp64.fp64.state_query one (i.e., what exactly is the error you get)
boqun has quit [Ping timeout: 480 seconds]
dtmrzgl has joined #dri-devel
boqun has joined #dri-devel
Danct12 has quit [Quit: WeeChat 3.8]
boqun has quit [Ping timeout: 480 seconds]
ice9 has quit [Read error: Connection reset by peer]
ice9 has joined #dri-devel
boqun has joined #dri-devel
headless has quit [Quit: Konversation terminated!]
boqun has quit [Ping timeout: 480 seconds]
smiles_1111 has joined #dri-devel
lemonzest has joined #dri-devel
boqun has joined #dri-devel
<karolherbst>
gfxstrand: I have bad news for you: we need alu ops in nir which will never flush denorms regardless of what the fp mode is
<karolherbst>
jenatali: you might be interested as well, because that's required for proper fp16 support
<jenatali>
karolherbst: The fp mode has separate states for fp32/fp16/fp64
<karolherbst>
yes, but no
<jenatali>
You can set a mode that's fp32 flush denorm, fp16 preserve
<karolherbst>
vstore/vload_half _can't_ flush
<karolherbst>
regardless of the mode
<jenatali>
Can't flush 32-bit denorms?
<karolherbst>
ehh
<karolherbst>
must not
<karolherbst>
never ever
<jenatali>
Are we talking about fp16 denorms or fp32 denorms?
<karolherbst>
so if the application wants denorm flushed, vload/vstore_half still mustn't
<karolherbst>
both
<karolherbst>
I guess?
<karolherbst>
but for now I indicate to drivers that fp16 shouldn't be flushed and that works for vload/vstore_half
<karolherbst>
the issue is once you advertize fp16, you also agree to the denorm madness
<karolherbst>
by default you can say you don't support denorms with fp16
<karolherbst>
_but_
<jenatali>
Oh, I see
<karolherbst>
vload/vstore_half still must not flush them
<karolherbst>
and we do this rounding conversion madness there as well
<jenatali>
The D3D spec only allows denorm control for 32bit, the requirements are no flushing for 16 or 64, so I didn't notice
<karolherbst>
ahh
<karolherbst>
I guess you don't advertize fp16 support in cl yet?
boqun has quit [Ping timeout: 480 seconds]
<jenatali>
No, I think I tried but something blew up
<karolherbst>
figures
<karolherbst>
-cl-denorms-are-zero is problem :P
<jenatali>
Doesn't that only apply to 32bit?
<jenatali>
Removing 16bit denorms really limits the usefulness of fp16
<karolherbst>
"This option is ignored for double precision numbers if the device does not support double precision or if it does support double precision but not double precision denormalized numbers i.e. CL_FP_DENORM bit is not set in CL_DEVICE_DOUBLE_FP_CONFIG."
<karolherbst>
at least
<karolherbst>
not sure about fp16
<karolherbst>
let me check..
<karolherbst>
I mean.. I wouldn't mind to advertize CL_FP_DENORM always
<karolherbst>
for fp16
<karolherbst>
jenatali: I think you might be right
<karolherbst>
`This option controls how single precision and double precision denormalized numbers are handled.`
<karolherbst>
and usually the spec already takes extensions like fp16 into account
<karolherbst>
sometimes
<karolherbst>
might want to file a spec bug to get some clarification on it
boqun has joined #dri-devel
<jenatali>
karolherbst: oh I think our software rasterizer blew up. WARP had some bad fp16 conversation logic IIRC
<karolherbst>
heh
<jenatali>
I recently fixed it for VK fp16
<jenatali>
At some point I should try CL again
<karolherbst>
yeah.. but I think just requiring CL_FP_DENORM is probably good enough
<jenatali>
I also finally fixed the bug with non-uniform indexing of constant buffers because VK hits it
<karolherbst>
and if drivers can't handle not flushing denorms then no fp16 for them I guess
<karolherbst>
nice
boqun has quit [Ping timeout: 480 seconds]
devilhorns has quit []
boqun has joined #dri-devel
<dolphin>
danvet, airlied: drm-intel-gt-next PR sent, will be OoO next week
chipxxx has quit [Remote host closed the connection]
<karolherbst>
I have a terrible idea for an optimization
<karolherbst>
make use of alignment information to know if adding an offset to a pointer won't touch the upper bits
<karolherbst>
so you could use 32 bit maths on 64 bit pointers
ice9 has quit [Ping timeout: 480 seconds]
Zopolis4 has quit []
<jenatali>
Is that really more efficient? Wouldn't that require splitting the pointer to be able to recombine the high bits
Leopold_ has quit []
<alyssa>
jenatali: that's free unless your compiler sucks
Leopold has joined #dri-devel
<jenatali>
Fair enough
<alyssa>
(in your specific case, your compiler being the underlying dx12 driver. it doesn't matter if you have some extra moves in your dxil.)
<jenatali>
Yeah, it'd be shifts and masks
<jenatali>
But it also doesn't matter because we already do all of our pointer math as 32bit because it's actually a buffer index in the high bits
<jenatali>
Also ugh another build break snuck in for the Windows build while it was disabled......
<alyssa>
13:29 < jenatali> Yeah, it'd be shifts and masks
<alyssa>
as I said. if the underlying backend compiler can't coalesce them it sucks :p
<jenatali>
Yeah
pcercuei has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
<karolherbst>
most will lower it to 32 bit anyway
<karolherbst>
and the next opt loop over that would tidy up all the masks
<karolherbst>
or whatever you have
<karolherbst>
but yeah.. the question is how to do that without making it hard to optimize
<karolherbst>
I mean.. nvidia hardware doesn't have 64 bit int ops anyway
<karolherbst>
sooo.. it's clearly a win there
<karolherbst>
actually
<karolherbst>
this is even simpler
<karolherbst>
we just have to replace the iadd with an ior
<karolherbst>
because check if the offset would touch any of the bits above alignment
madhavpcm has joined #dri-devel
<karolherbst>
though I can see the corner case of applying two offsets in a chain to the same pointer and stuff, mhhh
<karolherbst>
but then we'd have to track down the entire chain and could just do the or on the base ptr again?
yuq825 has left #dri-devel [#dri-devel]
kts has joined #dri-devel
<madhavpcm>
Hey I had to go offline, did I miss some reply to the earlier msg I put?
ice9 has joined #dri-devel
madhavpcm has quit [Quit: Leaving]
<jenatali>
karolherbst: You can't track down the entire chain, a pointer could've been stored in e.g. groupshared or scratch memory after a first addition
<karolherbst>
yes, and then we use the normal add
<karolherbst>
_but_
<karolherbst>
we still have the alignment information in a few places
pundir has joined #dri-devel
<karolherbst>
and we must be able to trust that information
btrfsbest has joined #dri-devel
<karolherbst>
I just don't think it will matter all that much, still an interesting experiment
madhavpcm has joined #dri-devel
btrfsbest has quit []
kawagucci has joined #dri-devel
dviola has quit [Remote host closed the connection]
kawagucci has quit []
dviola has joined #dri-devel
agd5f_ has joined #dri-devel
cazzacarna has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
cazzacarna has joined #dri-devel
cazzacarna has quit []
cazzacarna has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
<karolherbst>
might have to add a `from typing import List` as well
ice9 has quit [Ping timeout: 480 seconds]
<pundir>
@karolherbst "from list import List" helped move the build further, but now i'm stuck at "AttributeError: 'str' object has no attribute 'removeprefix'"
<karolherbst>
seems like we stopped being compatible with python 3.8 then
<karolherbst>
removeprefix was added in 3.9
<pundir>
ohh
<karolherbst>
could you file a bug and saying that mesa doesn't compile with python 3.8? Not sure if that's something we care about or not, but if ASOP still uses it, we might want to
<karolherbst>
*AOSP
<pundir>
so python 3.8.10 is ubuntu-20.04 problem and not an AOSP problem likely
<karolherbst>
right..
<pundir>
i'll try upgrading python version on my desktop and see if that helps
<pundir>
thanks a lot for your time @karolherbst
<karolherbst>
though I think if we require ptyhon 3.9 we should catch that earlier in the process
<karolherbst>
please report back if using python 3.9 works (or any other version you'd be using)
<alyssa>
I recall you lamenting not having clang-format enforced for i915g a while back, this would solve that at the cost of a little more CI
<alyssa>
With a bit more of a clear head then when I rage-closed that MR originally -- I guess I'm neutral
<alyssa>
I've locally added a pre-push script that does a clang-format lint, so even if I have a vim formatting fail, non-clang-formatted code should never leave my machine
<alyssa>
So it doesn't make a big difference to me and my workflow
<alyssa>
However it does change the calculus vaguely for drive-by contributions, unsure if for better or for worse.
<alyssa>
eric_engestrom: daniels: mupuf: as other CI stakeholders
<alyssa>
lina: bbrezillon: italove: as other driver stakeholders for panfrost & asahi
<alyssa>
(That MR enables the lint for Asahi, but Panfrost would presumably follow if it's merged. Currently Panfrost is not clang-format clean though that shouldn't be hard to fix.)
<eric_engestrom>
pundir: `from typing import List`, not `from list`
<eric_engestrom>
maybe you made a typo on irc and not in your code
* eric_engestrom
should read everything befor ereplying
<eric_engestrom>
alyssa: I think the cost is negligible (few seconds of CI), so the rate of false-positives (0 I expect), and the benefit is not having to care about reviewing formatting anymore, which is small but non-negligible, so in favour overall, but not strongly enough to argue over it :]
smiles_1111 has quit [Read error: Connection reset by peer]
pochu has quit [Quit: leaving]
<alyssa>
very fair
<alyssa>
the false positive risk I see is "drive-by contributor who doesn't know they need clang-format, we're so used to not reviewing formatting because we have proper editor configuration, we review their patch and assign to marge and the pipeline comes back red 4 hours later because the brace was in the wrong place"
<alyssa>
IDK if there's an effective way to mitigate that.
<alyssa>
otoh, if that MR is merged (status quo), then when I rebase there'll be a formatting fail so then my script wont
<alyssa>
let me push any of my code until I fix their fail
<alyssa>
which is not the end of the world either
<alyssa>
but not ideal
Ahuj has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<daniels>
yeah I don’t have any object to merging format as well as we can make it clear how people can do it locally
Kayden has quit [Quit: office]
<alyssa>
daniels: where would you like that documented specifically?
bmodem has quit [Ping timeout: 480 seconds]
* eric_engestrom
was asking themselves the same question
fxkamd has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
konstantin has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
JohnnyonF has quit [Read error: Connection reset by peer]
Kayden has joined #dri-devel
<daniels>
yeah + making sure that the CI job failure message gives a clear ‘run ./bin/indentme to fix this’ error message
<alyssa>
Not fully sure how to do that
<alyssa>
also would really love if someone wants to take over that MR because I am still not convinced this is a good idea which makes me the wrong person to drive it, lol
<alyssa>
(and because apparently studying full time while also working on multiple drivers is contra-indicated)
<alyssa>
daniels: any objection to merging as-is and improving the UX after? because not sure when I will have time to work on this again and regenerating the container isn't great
<alyssa>
(or at least merging the "add clang-format to the container" change now)
<alyssa>
(especially given the MR is now 2x r-b'd)
<daniels>
alyssa: sure, I’m on holiday so am hardly likely to spend much/any time on CI review
<alyssa>
oh, didn't realize. happy holidays then
<daniels>
grazie!
mbrost_ has joined #dri-devel
<alyssa>
"Merge blocked: the source branch must be rebased onto the target branch."
<alyssa>
uh
<alyssa>
shrug
<daniels>
Marge will do that
<alyssa>
yeah but i
<alyssa>
i did rebase it
<alyssa>
:p
pcercuei has quit [Quit: bbl]
mbrost has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
gallo72 has quit []
gallo72 has joined #dri-devel
Stary has quit [Read error: Connection reset by peer]
Stary has joined #dri-devel
g0b_ has quit [Remote host closed the connection]
g0b has joined #dri-devel
agneli has quit [Remote host closed the connection]
agneli has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
JoshuaAs- has quit [Ping timeout: 480 seconds]
JoshuaAshton has joined #dri-devel
<Lynne>
what's the penalty like for using VK_KHR_buffer_device_address instead of normal storage buffers on amd/intel?
<pendingchaos>
for AMD, 64-bit address calculation instead of 32-bit
<pendingchaos>
we can usually assume that different SSBO bindings don't alias each other, which helps conclude that memory read is read-only
<pendingchaos>
which can't be done with BDA
<dj-death>
Lynne: not much different for intel I think
<pendingchaos>
BDA doesn't have bounds checking, but it's mostly free with SSBOS, if you care about that
<pendingchaos>
otoh, BDA load/store can be vectorized more easily than SSBOs if robust_buffer_access2 is used, because there are no offset wraparound edge cases
<dj-death>
Lynne: for intel it's mostly descriptor_indexing that is costly
<Lynne>
interesting, I'd expect robustBufferAccess2 to make it slower rather than faster
<pendingchaos>
robustBufferAccess2 doesn't make it faster, it's just unaffected by robustBufferAccess2
<Lynne>
you can mark BDAs with write/read_only like regular buffers
<Lynne>
ah, I misread
<alyssa>
tangentially related but how are backend compilers supposed to decide which memory loads/stores need dependencies/waits/barriers and which don't?
<alyssa>
if there's a memoryBarrier() in the app that's an easy case but otherwise
pcercuei has joined #dri-devel
<alyssa>
presumably that hits some messy alias analysis, unless NIR is already helping with that somehow?
JohnnyonFlame has joined #dri-devel
<Lynne>
I was looking to use BDAs for compute with buffers ~100mb in size, so I'll go ahead with it, thanks
<Lynne>
maybe I'll convert everything to BDA while I'm at it, I don't need bounds checking, my code is perfect
<pendingchaos>
64-bit address calculation is rought 2x the cost of 32-bit address calculation
<pendingchaos>
so unless you need the functionality or helps vectorization a lot, it's probably slightly worse than normal SSBOs
<Lynne>
all my loads are sequential, so they're easily vectorizable
<pendingchaos>
the problem with ssbo vectorization is alignment, for example: a vec2 load at offset -4 wouldn't work, so we can only vectorize if we're sure that never happens or it's vec2 aligned
<Lynne>
that's why the buffer alignment has to be specified for BDAs
<Lynne>
my data is all just 4x4 matrices anyway
thenemesis has quit []
Major_Biscuit has quit [Ping timeout: 480 seconds]
<Lynne>
speaking of, I get roughly 4x the performance loss going from vectors to matrices for the prefix sum shader I have, aren't there dedicated matrix units?
Major_Biscuit has joined #dri-devel
<pendingchaos>
no, at least none that are useful for the matN GLSL type
<pendingchaos>
I think they require an extension to use and take fp16
<Lynne>
yeah, nvidia have an extension to use their tensor units in glsl, though theirs are fp32
<Lynne>
cooperative_matrix, sadly their compiler doesn't seem smart enough either to use them without it
Major_Biscuit has quit [Ping timeout: 480 seconds]
<airlied>
alyssa: is there a possible problem with clang-format version divergence?
<airlied>
also can you share your hook somewhere
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
pcercuei_ has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
<alyssa>
airlied: I've pinned a particular format (clang-format-13) both in CI and locally
<alyssa>
so version divergence should be limited to some churn once a version bump
<alyssa>
s/format/version/
<airlied>
i was more thinking on random contributor end
<alyssa>
oh. well random contributors need to pin the same version too then
<airlied>
or repeat fling at CI
<alyssa>
clang-format-13 is packaged in debian from oldstable to sid
<airlied>
which is what i do for all projects that enforce clang format
<alyssa>
idk what other distros do
<alyssa>
if other distros are only packaging a single version that might be trickier.
<alyssa>
fwiw lint passes on clang-format-14 too so hopefully not *too* much divergence
<DavidHeidelberg[m]>
let me enhance it just to be this train aesthetically pleasing: d3d8to9 -> nine -> zink -> dozen -> vkd3d-proton -> ashes -> virgl -> angle -> venus -> lavapipe
<DavidHeidelberg[m]>
btw. we could make contest. Who stack most of tech on top of each other and it still can render triangle :D
Fijxu has joined #dri-devel
<HdkR>
I'm sure you could stick FEX in there somewhere
<kisak>
need to add a contest rule to not repeat layers
<Fijxu>
work using `vkcube`. Any clue? I would ask this on #nouveau-vk but is kinda empty
<Fijxu>
Hello, i wanted to try NOUVEAU driver because the nvidia-open drivers are really a mess since i can't fully shutdown the GPU on there (Since i am using a Thinkpad with a 3070 Max-Q and the idle power is 11W and that is a lot) and well, it works better (in terms of power management) since the dedicated one fully powers off when is not used. But i wanted to try the NVK Mesa driver, i compiled and installed succesfully the NVK Mesa but vulkan doensn't
<Fijxu>
And of course i used DRI_PRIME=1 variable on every command
<airlied>
you want #nouveau more likely
Fijxu_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Fijxu has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
Fijxu_ is now known as Fijxu
<Fijxu>
airlied: Thanks, i will try to ask there ;)
<Fijxu>
This thing of nvidia is the only bad thing of my thinkpad power usage
ngcortes has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
vliaskov has quit []
Fijxu has quit [Remote host closed the connection]
Fijxu_ has joined #dri-devel
Fijxu has joined #dri-devel
Fijxu has quit []
Fijxu has joined #dri-devel
Fijxu_ has quit []
Kayden has quit [Quit: -> home]
ngcortes has joined #dri-devel
<Company>
random GL question: glTexParameter() - are those properties set on the texture referenced by the id or are they set on the texture unit of the current context?
<Company>
ir if context1 sets the filter of a texture, does that affect the filter of the same texture used in context2?
<Company>
*ie
pcercuei_ has quit []
<pendingchaos>
glTexParameter() affects the texture, not the texture unit
<pendingchaos>
so the sets the filter for both contexts (though I don't know if you can share textures across contexts like that)
fab has quit [Quit: fab]
<Company>
(you can, but properties are only guarantted to be synced at predfined sync points and a bunch of stuff is pretty undefined if both modify stuff at the same time)
<Company>
yes, I had to debug GLsync stuff recently
<Company>
so if I want to share texture data between 2 contexts but use 2 different filters in each, what's the best way to achieve that?
<pendingchaos>
sampler objects can be used to split the filter mode (and some other settings) from the texture object
<Company>
which is not in GLES2, hurray
<pendingchaos>
texture views, maybe? besides just constantly changing the filter mode
<pendingchaos>
looks like GLES2 doesn't have texture views
<Company>
that's GL 4.3+ only
<Company>
okay, but there are solutions, worst case we need to fallback to manual copying for GLES
Kayden has joined #dri-devel
gouchi has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
emersion has joined #dri-devel
nchery is now known as Guest7983
nchery has joined #dri-devel
mohamexiety has quit []
bgs has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
emersion has joined #dri-devel
pcercuei has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
fxkamd has quit []
nchery is now known as Guest7985
nchery has joined #dri-devel
smiles_1111 has joined #dri-devel
Guest7985 has quit [Ping timeout: 480 seconds]
Zopolis4 has quit []
anujp has quit [Remote host closed the connection]
soreau has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
rasterman has quit [Quit: Gettin' stinky!]
Leopold___ has joined #dri-devel
<alyssa>
Company: the short answer to multi-context GL is "don't"