ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
slattann has quit []
eukara_ has joined #dri-devel
eukara has quit [Read error: No route to host]
slattann has joined #dri-devel
<imirkin>
anyone seen this before: "Instruction node present twice in ir tree: (var_ref vec_ctor)" in dEQP-GLES2.functional.shaders.algorithm.hsl_to_rgb_vertex
<imirkin>
with a fresh checkout, but a slightly old VK-GL-CTS
<imirkin>
if not, i'll try to look at it in a few hours...
jhli has joined #dri-devel
aknautiy has joined #dri-devel
Ryback_ has joined #dri-devel
iive has quit []
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
<mattst88>
imirkin: yeah, that is because you need a ->clone() on a bit of IR that's used twice somewhere
<imirkin>
mattst88: yeah, i mean i've seen that kind of error before
<imirkin>
esp when devloping my own passes
<imirkin>
but i meant more like "in the tree, for dEQP tests"
<mattst88>
ahh
<imirkin>
also seeing something similar on dEQP-GLES3.functional.shaders.loops.short_circuit.while_vertex
<imirkin>
and its dEQP-GLES2 variant
slattann has quit []
icecream95 has joined #dri-devel
mhenning has joined #dri-devel
lygstate has joined #dri-devel
mhenning has quit [Quit: mhenning]
<imirkin>
happening all over the place... dEQP-GLES31.functional.layout_binding.ubo.vertex_binding_multiple sigh
mclasen has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
ella-0_ has joined #dri-devel
ella-0 has quit [Remote host closed the connection]
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
<imirkin>
wtf. fails on nv50, passes on nvc0?? those should be like 99% identical at the glsl level ... for a dEQP-GLES2 test
<imirkin>
sigh
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
<imirkin>
now to remember how to debug all this stuff... been so long since i've looked at glsl ir bugs
<imirkin>
hm, somehow lower_if_to_cond_assign is going wrong. and ... running differently between nv50 and nvc0 despite having identical params?
<imirkin>
oh, no, i see - MaxIfDepth comes out differently between them
YuGiOhJCJ has joined #dri-devel
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
lemonzest has joined #dri-devel
lygstate has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
Duke`` has joined #dri-devel
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit []
heat has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
dviola has quit []
pcercuei has quit [Quit: bbl]
i-garrison has quit []
i-garrison has joined #dri-devel
gouchi has joined #dri-devel
rasterman has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
<karolherbst>
duh.. " Address 0x4e0d880 is 0 bytes after a block of size 0 alloc'd"
<karolherbst>
and I was already wondering what's wrong
Haaninjo has joined #dri-devel
<karolherbst>
how did stuff even work before
<i-garrison>
karolherbst: guess that's why people love over-provisioning allocators )
icecream95 has quit [Ping timeout: 480 seconds]
nchery has quit [Read error: Connection reset by peer]
rkanwal has joined #dri-devel
mszyprow has joined #dri-devel
mclasen has joined #dri-devel
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
pcercuei has joined #dri-devel
rkanwal has quit [Quit: rkanwal]
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
garrison is now known as i-garrison
Haaninjo has quit [Quit: Ex-Chat]
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
garrison is now known as i-garrison
mszyprow has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
<Venemo>
jenatali: ping. can you tell what is the rounding mode of DXIL_INTR_LEGACY_F32TOF16? is it rtz or rte?
HankB__ has quit [Remote host closed the connection]
HankB__ has joined #dri-devel
<Venemo>
jenatali: thanks!
<Venemo>
jenatali: I see that you map NIR pack_half to this instruction, but I can't find any info whether the corresponding glsl opcode expects rtz or rte
<jenatali>
Venemo: I'd expect them to be the same, since that's clearly what hardware did at the time. Unless hardware was capable of both and D3D spec'd one while GL spec'd the other, which.. yeah that's happened a lot actually
mszyprow has quit [Ping timeout: 480 seconds]
<Venemo>
jenatali: is it possible for this D3D opcode to return fp16 infinity from any input that isn't fp32 infinity?
<jenatali>
> For source values greater than the dynamic range of a lower range target format (eg. a large 32-bit float value is written into a 16-bit float RenderTarget), the maximum representable (appropriately signed) value results, NOT including signed infinity
<jenatali>
So, no
<Venemo>
I see, okay
<Venemo>
apparently some VK drivers implementation (though I'm not sure which) can return infinity from non-inifinite inputs to GLSLstd450PackHalf2x16
<Venemo>
thx jenatali for clearing up the D3D behavior there
<jenatali>
Yep, no problem. I'm surprised GL doesn't have it spec'd one way or another
<jenatali>
You happened to catch me at a rare moment I'm actually here on a weekend these days :)
<Venemo>
it probably is spec'd somewhere, I'm just incredibly bad at finding this sort of info in any spec
<bnieuwenhuizen>
expecting GL(SL) to spec any kind of FP behavior usually results in a bad time
<Venemo>
jenatali: the VKD3D-Proton folks (who do the same work as yourself but in the opposite direction) actually found it necessary to add a workaround in shader code to check for infinity, because of how this GLSL opcode misbehaves on some VK drivers.
<jenatali>
Interesting
<Venemo>
sorry to ruin your weekend with this crap btw
<Venemo>
I didn't expect such a quick response :)
OftenTimeConsuming has quit [Remote host closed the connection]
heat has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<jenatali>
Nah no worries, was just sitting with some morning coffee
simon-perretta-img_ has quit []
simon-perretta-img_ has joined #dri-devel
simon-perretta-img_ has quit []
simon-perretta-img has joined #dri-devel
mszyprow has joined #dri-devel
h0tc0d3 has joined #dri-devel
khfeng has joined #dri-devel
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
garrison is now known as i-garrison
gouchi has quit [Remote host closed the connection]
khfeng has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<karolherbst>
jenatali: memory objects can me unmapped/mapped from any queue, can't they?
<jenatali>
Yep pretty sure
<karolherbst>
and here I thought I could keep using Drop in Rust to clean up my pipe_transfer objects :(
<karolherbst>
jekstrand: ... soo here is an idea. As we have to deal with pipe_transfers maped on one context and unmap on another one.. couldn't we just use the helper context to create async mappings? I do have an impl for that and it does seem to work out alright I have to get rid of this auto drop stuff for transfers as well, because the context could change.
gouchi has joined #dri-devel
<nanonyme>
ajax, hey, got a moment? Where's the rpm definition for Fedora Mesa amber? I'm trying to package it and thought could use definitions from Fedora as example
<kisak>
Debian/Ubuntu and Arch have amber packages to use as a reference at least
<karolherbst>
jekstrand: also.. I found the leak :) I don't kill mappings when the memory object gets destroyed
<karolherbst>
ehh wait.. that should happen regardless
<karolherbst>
nvm then
h0tc0d3 has quit [Remote host closed the connection]
h0tc0d3 has joined #dri-devel
Akari has joined #dri-devel
maxzor has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
MajorBiscuit has joined #dri-devel
<nanonyme>
kisak, looks like it's still in proposed in Ubuntu. Hm.
<kisak>
I'm not seeing how that's marked proposed.
<karolherbst>
ohh we got rid of classic drivers, I kind of missed that part :)
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
slattann has joined #dri-devel
gawin has joined #dri-devel
h0tc0d3 has quit [Quit: Leaving]
slattann has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
<linkmauve>
I just found out an old Pentium 4 laptop, with an (according to glxinfo) 852GM/855GM; would it use crocus or i915 on a more recent release of Mesa?
<linkmauve>
(The thing runs Ubuntu 8.04 atm.)
flto has quit [Quit: Leaving]
<karolherbst>
linkmauve: wow, that's ancient stuff :D