<bnieuwenhuizen>
anyone know if serialized nir is supposed to be portable across CPU architectures/ABIs?
<bnieuwenhuizen>
(assuming all little endian. I'm not *that* crazy)
vivijim has joined #dri-devel
<HdkR>
bnieuwenhuizen: Doubt
camus has joined #dri-devel
<HdkR>
I'm of the opinion that unless you have CI actively checking for cross-arch packing differences then they will just naturally creep in
<airlied>
yeah I'd agree on that :-P
<airlied>
it might accidentally be portable right now, but tomorrow it might not
<HdkR>
I'd recommend generating some libclang tooling that guarantees this that lives in CI if you actually want this. Which is why I have struct packing verification in FEX for this exact problem :)
vivijim has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
<bnieuwenhuizen>
alternative might just be to do stuff in spir-v instead if I want things to be portable
<airlied>
bnieuwenhuizen: just adopt CL C :-P
<bnieuwenhuizen>
airlied: hey I'm trying to avoid having to ship and parse libclc at runtime :P
<bnieuwenhuizen>
since my set of kernels is known at (mesa) compile time I thought it might be worth to ship stuff post-linking
<bnieuwenhuizen>
but if SPIRV is the portable thing that means linking in SPIRV, kinda annoying
* bnieuwenhuizen
makes premature optimization noises
vivijim has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
unerlige has joined #dri-devel
boistordu_ex has joined #dri-devel
boistordu has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
mattrope has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
nuh^ has quit [Remote host closed the connection]
crabbedhaloablut has joined #dri-devel
mattrope has quit [Remote host closed the connection]
illwieckz has quit [Remote host closed the connection]
<imirkin>
hrmph. i'm seeing a deqp test which lists the "reference" and "rendered" images as *identical* png's, and yet the error mask is all red (and the test fails)
<imirkin>
what might cause that?
mszyprow_ has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
<imirkin>
ah, looks like alpha was off. i think.
cphealy has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
tarceri_ has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
mszyprow_ has joined #dri-devel
illwieckz has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
danvet has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
<MrCooper>
vsyrjala: the current API defines the deadline to be start of vblank; the dotclock can be determined based on the current start of scanout timestamps as well?
tzimmermann has joined #dri-devel
rgallaispou has joined #dri-devel
jkrzyszt has joined #dri-devel
pnowack has joined #dri-devel
Haaninjo has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
mszyprow_ has joined #dri-devel
pcercuei has joined #dri-devel
gawin has joined #dri-devel
ella-0 has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
ella-0 has joined #dri-devel
tursulin has joined #dri-devel
ddevault has quit [Remote host closed the connection]
ddevault has joined #dri-devel
aravind has joined #dri-devel
camus has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
camus1 has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
mlankhorst has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
mclasen has joined #dri-devel
Peste_Bubonica has joined #dri-devel
Peste_Bubonica has quit [Remote host closed the connection]
Peste_Bubonica has joined #dri-devel
Peste_Bubonica has quit []
Peste_Bubonica has joined #dri-devel
Guest6943 has quit []
imre has quit [Quit: leaving]
imre has joined #dri-devel
thellstrom has joined #dri-devel
vivijim has joined #dri-devel
ddevault has quit [Remote host closed the connection]
<emersion>
see "If your patch fixes a bug in a specific commit […]"
<xx1>
Ok, thanks a lot!
<xx1>
see you!
xx1 has left #dri-devel [Leaving]
<dj-death>
is nir_opt_copy_prop_vars() supposed to work on shader that have already lowered their variables?
Peste_Bubonica has quit [Remote host closed the connection]
Peste_Bubonica has joined #dri-devel
jewins has joined #dri-devel
<pendingchaos>
I don't think nir_opt_copy_prop_vars() is expected to optimize anything after lowering, and I don't think it should miscompile the shader
<dj-death>
there are a bunch of expectation in there
<dj-death>
for some intrinsics (like atomics) a deref is expected as a source
<dj-death>
so it just crashes if you run it after lowering
<dj-death>
not quite sure where I should put my fix
<dj-death>
either change the backend not to call it
<dj-death>
or change the NIR pass
<dj-death>
I guess backend change is the easy route :)
mattrope has joined #dri-devel
<dj-death>
opt_combine_stores() seems to have the same assumptions
<pendingchaos>
after lowering, the intrinsics should be replaced with ones which don't expect a deref as a source
<pendingchaos>
like nir_intrinsic_store_deref should be replaced with nir_intrinsic_store_ssbo or nir_intrinsic_store_shared (or none, in the case of nir_lower_vars_to_ssa)
<FLHerne>
hardcoding profiles for benchmarks seems dubious, surely that should be in driconf at least?
<dj-death>
I think I see the problem now :)
<dj-death>
we don't have non deref version of ray tracing intrinsics
<FLHerne>
I mean, the only purpose of a benchmark is to estimate how fast other things will run, so a hardcoded profile that speeds up only a specific benchmark and can't be used for other apps makes no sense
<karolherbst>
I kind of see why that helps, but...
macromorgan is now known as Guest7148
macromorgan has joined #dri-devel
Guest7148 has quit [Remote host closed the connection]
<karolherbst>
I wished it wouldn't
xantoz has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
Duke`` has joined #dri-devel
<gawin>
mareko: quick question as the documentation is a bit weird here: the offset is uint32, but memory for it starts at 5th bit (so 26bits from 32bits), so offset should nuke first 5 first bits or 5 last bits?
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
mszyprow_ has joined #dri-devel
fxkamd has joined #dri-devel
<imirkin>
anholt: the deqp-runner timeout ... what precisely is it waiting on? open()? read()? (the message says "for fd to be ready"...)
<agd5f>
gawin, it means the address is 32 byte aligned (e.g., bits 0-4 are 0)
<imirkin>
i'm seeing some timeouts over nfs on a local gbit network ... i know nfs sucks, but can't be that bad. i guess something in the kernel could be wedging it though, e.g. a hangcheck?
<imirkin>
(timeout is set to its default 60s value...)
<agd5f>
gawin, the code is correct
Peste_Bubonica has quit [Quit: Leaving]
tzimmermann has quit [Quit: Leaving]
soreau has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
soreau has joined #dri-devel
<karolherbst>
imirkin: some tests just take that long?
<imirkin>
karolherbst: it's not about how long tests take
<imirkin>
it's about reading the results file
<karolherbst>
ohh...
aravind has quit []
mszyprow_ has quit [Ping timeout: 480 seconds]
kenjigashu has joined #dri-devel
kenjigashu has quit []
mszyprow_ has joined #dri-devel
kenjigashu has joined #dri-devel
kenjigashu has quit []
iive has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
rgallaispou has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
Guest4637 has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
kenjigashu has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
flibitijibibo has quit [Quit: Leaving]
ybogdano has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
ybogdano has joined #dri-devel
ngcortes has joined #dri-devel
kenjigashu has quit [Ping timeout: 480 seconds]
mszyprow_ has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
gawin has quit [Read error: No route to host]
gawin has joined #dri-devel
gouchi has joined #dri-devel
flibitijibibo has joined #dri-devel
kenjigashu has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
boistordu_ex has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
I don't suppose GenXML has a schema anywhere?
Company has joined #dri-devel
<alyssa>
It'd be nice to be able to add comments to the XML (where the name isn't descriptive enough) in a formal way
<alyssa>
(I.e. not <!-- ... --> blocks which is what I do now. But that doesn't work with e.g generating documentation)
<alyssa>
anyways, would like to remain close to intel and broadcom style genxml
tjaalton has quit [Quit: Lost terminal]
ngcortes has quit [Remote host closed the connection]
kenjigashu has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
mbrost has joined #dri-devel
boistordu has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
rcf has quit [Quit: WeeChat 3.2.1]
gouchi has quit []
rcf has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
enilflah has quit [Read error: Connection reset by peer]
enilflah has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
mszyprow_ has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
<imirkin>
Kayden: will you (intel) be taking steps to integrate crocus as the "main" driver, or will i965 / amber or whatever remain the intel-supported solution for pre-gen8 chips?
ngcortes has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<airlied>
imirkin: apart from CI is there anything else they can do?
<airlied>
I doubt Intel still supports those GPUs in the real world for most things
* airlied
glances at ngcortes to see if crocus CI run ever completed
<imirkin>
airlied: well, i965 is a battle-tested fairly stable driver. crocus is ... not. i expect it to have shortcomings, some of which will be very difficult to track down
<Kayden>
I would certainly like to see the Intel Mesa team help fix any bugs that pop up with crocus vs i965, so that crocus becomes the officially supported driver we recommend to everyone going forward
<Kayden>
the fact that it's been shipping in Fedora already gives me hope that it's in pretty good shape already, but yeah, I expect there will be more things that pop up as it gets adopted more widely
<imirkin>
cool
<airlied>
I think it just needs a lot more users at this point
<Kayden>
that said, we do barely work on that hardware on i965 at this point, so I am unsure whether anyone will have a lot of time to devote to it
<imirkin>
yeah, i mean crocus _basically_ works. but i think you know full well that "stuff" pops up with wider usage, which will become increasingly obscure and hard to track down
<airlied>
like I'm not really rushing to fix nine on crocus issues
<Kayden>
I know personally I feel pretty bad about having done basically beans to help out with crocus
<airlied>
but any old workloads that don't work on crocus I'm trying to react quicker
<Kayden>
Yeah, that's fine I think - people can fix nine issues over time. It didn't work before, it can be made to work in time
<imirkin>
sure
<Kayden>
it sounds like for VK+GL usage, we're going to be trying to support anv+crocus on main, too, and not anv-main+i965-amber
<Kayden>
which makes sense to me
<imirkin>
i guess i was just looking for a "yeah, we'll try to support it" (or not) comment
<Kayden>
I think we should
<Kayden>
one thing of note... there are fewer and fewer people on the Intel team at this point that actually worked on any of that hardware, though. :(
<airlied>
the only area I've been a bit unsure about is aperture sized batch submissions
<Kayden>
hah
<imirkin>
Kayden: ... or were born before that hardware was released? :)
<airlied>
since on the newer stuff that is rarely a problem
<ngcortes>
airlied, ah, I need to add the crocus daily job to the external site whitelist
<airlied>
but the 965/gm45 area I'm a bit unsure I covered all the bases
<Kayden>
airlied: the good news is that shit never worked anyway
<Kayden>
well. there were fixes. it may have mostly worked
<Kayden>
but it was pretty much fueled by hopes and prayers
<airlied>
like I ported a lot of it, but interactions around blorp etc not sure
<Kayden>
might need some fixing up then, yeah
<airlied>
but it's one of those, not sure what test is best for figuring it out
<airlied>
these machines have small amounts of RAM, so the leak tests OOM fairly quick :-P
<Kayden>
hmmmm....globallogic had some patches around that
<Kayden>
we could probably dig up whatever they had been using to provoke the problems
Haaninjo has quit [Quit: Ex-Chat]
<Kayden>
it's also possible to just restrict the aperture limit on later HW
<Kayden>
to just artifically flush more
<Kayden>
and do whatever rollback nonsense there is
<Kayden>
that's probably what I'd do, that way you can test more advanced things on machines with actual memory
<Kayden>
but still test the "oops, we can't handle that large of a batch" path
<anholt>
ajax: de-relocationing nir_opt_algebraic is a little messier than I was hoping for today.
<anholt>
I have to decide if I move the struct type tag from the struct to the references to the structs, or if we'd actually be better off with a union for storing all the struct types together in one table.