ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
sima has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
jfalempe has quit [Quit: jfalempe]
CME has quit [Ping timeout: 480 seconds]
HerrSpliet has joined #dri-devel
RSpliet has quit [Ping timeout: 480 seconds]
Calandracas has joined #dri-devel
CME has joined #dri-devel
<alyssa>
pac85: fair point. gl stands for gallium =D
marc2377_ has quit []
<alyssa>
cmarcelo: hmm. the reason I want this is specifically *so* grep works properly. grepping src/asahi should get everything in the driver. the AGX compiler shouldn't be #included outside src/asahi. etc
<alyssa>
right now it's src/asahi and also src/gallium/drivers/asahi if the GL driver is touched
<alyssa>
only reason to keep in src/gallium/drivers is so mareko doesn't get annoyed about gallium drivers disappearing, I guess
<alyssa>
(so that grepping src/gallium/drivers hits all the gl drivers)
<alyssa>
idk if a symlink is the right tool for that though
heat has quit [Ping timeout: 480 seconds]
kj2_ has joined #dri-devel
ellyq_ has quit []
epoch101 has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
anholt has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
glennk has quit [Ping timeout: 480 seconds]
amarsh04 has joined #dri-devel
<benjaminl>
is there a rule of thumb for when a new nir pass should go in src/compiler vs a driver-specific directory?
<benjaminl>
(context is I'm currently looking at writing a pass to lower noperspective varyings for hardware that doesn't have linear varying interpolation. Afaik this only applies to panfrost, but in theory it's general)
mbrost has quit [Ping timeout: 480 seconds]
kasper93 has joined #dri-devel
Daanct12 has joined #dri-devel
edolnx_ has joined #dri-devel
edolnx has quit [Ping timeout: 480 seconds]
alane has quit []
alane has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
mdroper has quit [Ping timeout: 480 seconds]
paulk has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
The_Company has joined #dri-devel
mbrost has quit [Remote host closed the connection]
jernej has quit [Read error: Connection reset by peer]
jernej has joined #dri-devel
<alyssa>
benjaminl: "is this useful for multiple drivers", pretty much
<alyssa>
I tend to be a fan of "incubate in driver, then the second driver who wants to use it can move to common code" guaranteeing common passes have 2 users
<alyssa>
not a hard rule though
<alyssa>
what was the problem with noperpsective on mali thenÉ
<alyssa>
what was the problem with noperspective on mali though?
androidui has quit [Remote host closed the connection]
ZLangJIT has joined #dri-devel
ZLangJIT is now known as androidui
tzimmermann has joined #dri-devel
androidui has quit [Remote host closed the connection]
ZLangJIT has joined #dri-devel
ZLangJIT is now known as androidui
kode54 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
kj2_ is now known as kj2
kts has joined #dri-devel
kode541 has joined #dri-devel
kode54 has quit [Ping timeout: 480 seconds]
jfalempe_ has joined #dri-devel
jfalempe has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
kts has quit [Quit: Leaving]
jkrzyszt has joined #dri-devel
kts has joined #dri-devel
kts has quit [Quit: Leaving]
pixelcluster has quit [Ping timeout: 480 seconds]
pixelcluster has joined #dri-devel
heat has joined #dri-devel
warpme has quit []
androidui has quit [Remote host closed the connection]
ZLangJIT has joined #dri-devel
ZLangJIT is now known as androidui
sima has joined #dri-devel
pcercuei has joined #dri-devel
rgallaispou has joined #dri-devel
mahkoh has joined #dri-devel
kode541 has quit []
kode54 has joined #dri-devel
<mahkoh>
Hi, VkSwapchainCreateInfoKHR allows the client to pass in an oldSwapchain. The spec only requires the oldSwapchain to have been created from the same device, only the same instance. But mesa performs an unconditional cast to its internal swapchain type. Am I missing some part of the spec that requires the oldSwapchain to have been created from the same device?
<mahkoh>
uhh, I meant the spec DOES NOT require the oldSwapchain to have been created from the same device
warpme has joined #dri-devel
nerdopolis has joined #dri-devel
<emersion>
doesn't same instance imply same device?
<mahkoh>
The instance is the top-level object that can be used to enumerate devices. On systems with an nvidia GPU and an AMD GPU, the same instance can be used to create mesa and nvidia devices.
<mahkoh>
The SurfaceKHR type is defined in vk_icd.h which is shared by all drivers. But swapchains seem to always have a driver-defined layout so sharing swapchains between devices should always lead to undefined behavior.
<zmike>
might be a spec oversight
<mahkoh>
I guess this is just an oversight. vkDestroySwapchain requires that the swapchain was created from the given device.
<zmike>
raise an issue
<mahkoh>
Ok
<zmike>
on the spec
rgallaispou has quit [Remote host closed the connection]
<bromiumse>
happens, where each power has the multiplier later on, and a remainder that is interpreted per sum of invariant operands and translated to by the accessed alu operations result. That paper gives the same results, the implementation is not really needed (but you can also find free doi of the reference 15, compression ration is way neyond winzip there so 0.05 vs 0.343
<bromiumse>
https://www.sciencedirect.com/science/article/pii/S0304397511009418?via%3Dihub). max number is presented by log (L,n) bits. which comes back as 10 bits per 4.2Billion. So the system ddrm procedures are broken due to bad PCIe bugs, well read-modify-write is needed and dma, unaligned is not a requirement, as shifting can be performed on host? Mr Shannon was a smart man, i did not fully
<bromiumse>
understand his chess take on things though, but powers in computer is likely simpler than chess paradigm.
<mahkoh>
Is it possible to recover from vkQueuePresentKHR failing? It seems that mesa updates the state of the image (acquired) somewhere in the middle of its logic, which means that the client cannot use the image anymore. The spec doesn't seem to say anything about this.
<mahkoh>
For a wrapper, would it be best to discard the swapchain at that point?
<daniels>
depends on the return - afaict the only failures after the implementation takes ownership of the image are VK_OUT_OF_DATE_KHR, which is pretty clear that you can no longer use the swapchain
<stsquad>
has anyone tried debugging mesa/virglrenderer with rr? is swrast fallback the only way to go?
OftenTimeConsuming has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<mahkoh>
I see several goto fail_present before and after the acquired field has been reset.
<mahkoh>
For example, result = wsi_signal_dma_buf_from_semaphore(swapchain, image), which does not look like it would return VK_OUT_OF_DATE_KHR.
<indopaster>
if you look at that this way, you can only have somewhere around 1024 combinations, when the operands become known there will be round robin pinning, which produces less than 1024*1024 non-ordered combinations, hence there is no carry handling anymore, cause carry is already handled by invariance you could pin based of the truth table but the result of binary multiplication would come to
<indopaster>
the same solution, as for operand multiplication and encoded to invariant contiguous weights. There is quite few doubt that this pdf is correct, because, it's the decoder which will output all the not used bits 1024*1024*1024*4-1 is the max, 1024 is the operand 1 powers combination count, second is the other operands comb_count, result is the combinations of decoder+result and *4 is
<indopaster>
handling the carry. So *4 is handled by invariance, 1024*1024 is handled by access table through sums and *1024 of result is handled by the results which are prepinned. The results are so sparse, cause the collisions at higher powers are met so often.so 1024 mersenne number is 1023, where as 1024 is 32+11+11 the mersenne of that is larger in encoded format but results of the access are
<indopaster>
smaller or bigger for multiply alu but the translation of decoder is bigger, in other words it can use collisions as intermediate results and hence the outcome is the same, and it's not like united states or british military did not know what i talked about, russian language i am learning, cause british and us sent me 2years of feedback on such things, this method is known as electrical
<indopaster>
suppression for the bright headed people. and is achieved with routines over plus and minus. In hw without opcodes reloaded you can not have transition from small electricity to bigger per opcode AFAIK. Now PCIe troubles i dunno very well,i was never close to their development for hw nor sw. I know that this is an interrupt based third party dma which needs to be used, it needs reliable
<indopaster>
pcie encoding and timing likely indeed. We would really fancy putting the bursts there in fact, it's very low power as well as fast there and pretty easy to develop.
kts has quit [Quit: Leaving]
tzimmermann has quit [Quit: Leaving]
anarsoul has joined #dri-devel
<airlied>
sima: do we care about kunit tests causing lockdep warnings :-)
<Lyude>
drm-tip conflict detected, taking a look now
coldfeet has joined #dri-devel
<airlied>
Lyude: oh I'm solving it here
<airlied>
was just waiting for a rebuild
<airlied>
Lyude: pushed it
paulk-bis has joined #dri-devel
paulk has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
<Lyude>
airlied: ah cool, got to me first then :P
<Lyude>
erm, got there first I mean
alanc has joined #dri-devel
testaccount has joined #dri-devel
testaccount has quit []
testaccount has joined #dri-devel
testaccount has quit []
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
yuq825_ has joined #dri-devel
yuq825 has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
dviola has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
redsocketdown has joined #dri-devel
redsocketdown has quit [Remote host closed the connection]
mbrost has joined #dri-devel
dualperform has joined #dri-devel
gouchi has quit [Remote host closed the connection]
enunes- has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
enunes has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<airlied>
mlankhorst: can you apply Arnd's patch to fix imx/dcss/dcss-kms.c to drm-misc-next and send me a new PR?
<airlied>
the current PR doesn't build for me here
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
<benjaminl>
alyssa: the problem with noperspective on mali is that the only available instructions to load varyings do perspective-correction. LD_VARY*.clobber *almost* does the right thing but not quite
<alyssa>
ouch
<alyssa>
yeah, ok. frustrating
<benjaminl>
hahaha yeah. The docs I have for G610 say that .clobber is supposed to do noperspective, but the docs for later chips just say it's undefined
<alyssa>
entertaining
<benjaminl>
possibly it was intended as noperspective but hardware bug?
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<alyssa>
I'd believe it
<alyssa>
but "change the docs to match the bug" instead of "fix the bug" is just
<alyssa>
chefs kiss
<benjaminl>
:)
<alyssa>
I guess Mali doesn't have any way to do per-vertex varying loads either
<alyssa>
(neither does Imaginapple but still)
<benjaminl>
plan is to "undo" the perspective correction by writing 'v * w' in the vs and then multiplying by gl_FragCoord.w in the fs
<benjaminl>
and yeah, no per-vertex varying loads
Lizhi has joined #dri-devel
<alyssa>
ouch
<alyssa>
any clue what the DDK does?
<benjaminl>
not even possible to fake it by loading directly from the vertex packet buffer afaict
<benjaminl>
I asked a DDK dev but haven't heard back yet
<benjaminl>
I should really get around to setting up pandecode
Lizhi has quit [Remote host closed the connection]
vsyrjala_ is now known as vsyrjala
gouchi has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
enunes has joined #dri-devel
enunes- has quit [Ping timeout: 480 seconds]
enunes- has joined #dri-devel
enunes has quit [Ping timeout: 480 seconds]
enunes- has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
dviola has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]