<narmstrong>
pcercuei: i pushed a fix on drm-misc-next yesterday, can you check if it doesn’t already fix your issue ?
<narmstrong>
pcercuei: it fixes the case when dw-hdmi is the first bridge
<pcercuei>
I believe you mean 1528038385c0 ("drm/bridge: dw-hdmi: use safe format when first in bridge chain")
<pcercuei>
I'll take a look, thanks
<pcercuei>
It should however never be the first bridge, that would be ingenic-drm's internal bridge. And on the other side we have hdmi-connector
kts has joined #dri-devel
<narmstrong>
pcercuei: i misread the patch, yep it’s definitely ok
<narmstrong>
pcercuei: I’m off next week, I’ll review it properly then
<pcercuei>
Ok, I'll wait for your review then
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
<anholt>
hrm. r600 sb is broken, even after it's been disabled for all sorts of codepaths, but also it's still worth a 40% instruction count win over non-sb.
<imirkin>
sb is definitely imperfect
<imirkin>
esp in GL 4.2+ use-cases (images, ssbo, etc)
<anholt>
yeah, it's just disabled for those.
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
<anholt>
huh. shader with "in vec4 eON_VARYINGS[10]" and only [0] used, but the variable declaration wasn't trimmed. I thought something in linking would do that for us.
<imirkin>
also sb operates on the AMD ISA directly, and there is no "virtual register" numbering implemented, so if you use more than 128 TGSI TEMPs, you're sunk
<anholt>
sb does too? oof.
<imirkin>
sb doesn't consumer TGSI
<imirkin>
it consumes the terascale ISA directly and "manipulates it" so to speak
<anholt>
yeah, I guess that makes sense
<anholt>
it comes after the rest of r600_shader
<imirkin>
so if it's not representable there, then you're screwed
<imirkin>
there have been efforts to go tgsi->sb and more recently, nir->sb, but afaik neither was complete
<anholt>
yeah, I hear gerddie is rewriting the whole thing, but it's a free time project so not going fast
<jenatali>
imirkin: Yeah, that needs to be added to a skip list
<jenatali>
I wish we were using deqp-runner, having a flake list that're run but allowed to fail would be nicer than having to skip them and update our expectations accordingly :(
<jenatali>
It's pretty infrequent, maybe 5% hit though
<imirkin>
i assume there's some reason why you're not...
<jenatali>
Doesn't work on Windows
<jenatali>
(Yet)
<imirkin>
that's a pretty good reason
mszyprow has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
agd5f_ has joined #dri-devel
<alyssa>
jenatali: ..why not run in WSL2?
<jenatali>
alyssa: the Windows machine is a VM, so WSL would require nested virt, and would require an actual GPU to be projected to the Windows host
<jenatali>
Also the Windows machine is running server 2019 which doesn't have GPU support in WSL
agd5f has quit [Ping timeout: 480 seconds]
<imirkin>
is iris-glk-traces-performance supposed to take 25min+ to complete?
<imirkin>
(should it be renamed to no-performance?)
<imirkin>
ah no, a lot more than twice. i guess 5x...
gouchi has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
<airlied>
imirkin: the evergreen abi docs should cover most stuff i thought but its been a while
<imirkin>
anholt: --^
<airlied>
sfn is gerddies thing
<airlied>
doh thx , meant anholt
<airlied>
sb is really rewrite it all is faster than fixing it, maybe dschuermann will got bored and realise vliw is more interesting :-p
fxkamd has quit []
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
fxkamd has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
<dschuermann>
airlied: will if you do a level-zero implementation for GCN :P
dllud has quit [Read error: Connection reset by peer]
<robclark>
danvet: btw, for userspace allocated gem handles, I guess we'd also need to add a flag to PRIME_FD_TO_HANDLE to avoid stalling on dma-buf import.. for things that re-import every frame.. but there is already a flags field there so I guess not so bad
fxkamd has quit []
dllud has joined #dri-devel
<danvet>
robclark, yeah for that one we probably then also want an out-flag that tells you that you have this already
<danvet>
which might break this, or I'm not sure how you'd cope :-/
<danvet>
or just accept that you can map the same buffer multiple times or something like that
<robclark>
oh.. hmm.. yeah, that would be a bit awkward to deal with.. unless we just allowed multiple handles per obj
<danvet>
but means you need driver support for that
<danvet>
robclark, it's not the multiple handles, but the multiple mappings your driver needs to cope with
<robclark>
right
<danvet>
the multiple handles are no problem at all for the kernel
<robclark>
I guess the other approach is keep kernel assigned handles, but try hard to not actually care what the handle is until submit/execbuf time
<robclark>
hmm, but no.. we would still have the iova issue.. bleh
kts_ has joined #dri-devel
kts_ has quit []
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
lkw has quit [Quit: leaving]
hch12907_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
agd5f_ has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
heat has joined #dri-devel
agd5f has joined #dri-devel
Haaninjo has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
hinged has joined #dri-devel
hinged has quit [autokilled: This host has violated network policy. Mail support@oftc.net if you feel this is in error. (2022-02-12 23:39:17)]