mbrost has quit [Remote host closed the connection]
sdutt has joined #dri-devel
GloriousEggroll has quit [Quit: Death is life's way of telling you you've been fired.]
<robclark>
pinchartl: hmm, do any drivers support R8 or R16 scanout? I could kinda imagine that those formats are only defined for the benefit of userspace (ie. for things like nv12 fallback samples-as-two-textures).. does any driver support R8/R16 greyscale scanout? I've not seen greyscale displays since the dark old ages of giant glass tubes.. but I guess if you have a use-case defining more drm fourcc's is ok
sdutt has quit [Ping timeout: 480 seconds]
Lightkey has quit [Ping timeout: 480 seconds]
Lightkey has joined #dri-devel
pendingchaos has quit [Read error: Connection reset by peer]
pendingchaos has joined #dri-devel
sdutt has joined #dri-devel
<pinchartl>
robclark: I have a use case on the camera side :-)
<robclark>
hmm, ok.. I think you should assume anything missing in drm_fourcc.h is just things no one else needed yet, and send a patch to add what you need ;-)
<pinchartl>
ok. I'll prototype first, and eventually send a patch then
<pinchartl>
thanks for the feedback
heat has joined #dri-devel
camus has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
<robclark>
np
boistordu_old has joined #dri-devel
sarnex has quit [Quit: Quit]
boistordu has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
heat has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
sagar__ has joined #dri-devel
sagar_ has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
vivijim has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
sagar_ has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
sagar__ has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
Lyude has quit [Quit: WeeChat 3.0.1]
YuGiOhJCJ has joined #dri-devel
<anholt>
jekstrand: I'm heading out camping tomorrow, not sure if I'll have time to check on or push any MRs.
itoral has joined #dri-devel
Lyude has joined #dri-devel
aravind has joined #dri-devel
NiksDev has joined #dri-devel
mceier has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
frieder has joined #dri-devel
<glennk>
robclark, R8 scanout = C8 with an identity color map?
mceier has joined #dri-devel
Duke`` has joined #dri-devel
sagar_ has quit [Remote host closed the connection]
sagar_ has joined #dri-devel
pochu has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
danvet has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
kusma has quit []
kusma has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
bcarvalho_ has quit []
mceier has quit [Ping timeout: 480 seconds]
kusma has quit []
kusma has joined #dri-devel
<pq>
glennk, that's what I'd guess, but at least with C8 you know what color you get. If you scan out R8, do you get gray shades or red shades? :-)
<pq>
hmm, wonder what the EDID colorimetry for a monochrome non-gray display would look like...
mceier has joined #dri-devel
<pq>
if it was a monochrome display, then all chromaticities and white point would be the same point, right?
<pq>
but if it's single-channel di-chromatic, like white/blue...
<glennk>
can toss in C12 format which some ancient hardware supported
<pq>
clearly we need I12 and L12 formats
<pq>
..not
Ahuj has joined #dri-devel
pcercuei has joined #dri-devel
lynxeye has joined #dri-devel
bcarvalho has joined #dri-devel
flto_ has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
camus has quit [Remote host closed the connection]
pochu has quit [Read error: Connection reset by peer]
pochu has joined #dri-devel
<mriesch>
hi all. i am trying to port a minimal driver for the rockchip vop2 from the sdk to mainline and i am stuck at the point where the framebuffer dev should probe. the error message is "Cannot find any crtc or sizes"
frieder has quit [Remote host closed the connection]
<mriesch>
apparently, all mode_set are zero so who sets these in the first place?
<danvet>
probe callbacks on the connecor provide the mode list
<danvet>
plus well everything linked from there should get you started
<tzimmermann>
airlied, danvet, drm-misc-next-fixes is empty. no PR this week
<danvet>
mriesch, also I strongly recommend you bring up your driver without fbdev/fbcon at first
<danvet>
and just use kms interface directly with maybe modetest or whatever from libdrm
<danvet>
or igt tests
<mriesch>
danvet, thanks for the pointer(s)
<danvet>
the locking with fbdev on top is nasty and often means you just die silently
<mriesch>
danvet and thanks for the hint. actually, i am just trying to bring the connector up to test the recent dw_hdmi patches
<mriesch>
everything else is a plus at the moment :-)
pnowack has joined #dri-devel
xexaxo_ has joined #dri-devel
<dj-death>
emersion: looks fine to me
<emersion>
alright, thanks!
xexaxo has quit [Ping timeout: 480 seconds]
xexaxo_ has quit [Ping timeout: 482 seconds]
adjtm has quit [Ping timeout: 480 seconds]
raket has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<airlied>
a
ramaling has quit [Remote host closed the connection]
<MrCooper>
let me one-up that: b
ramaling has joined #dri-devel
icecream95 has joined #dri-devel
<icecream95>
å
lynxeye has quit [Ping timeout: 480 seconds]
xexaxo_ has joined #dri-devel
flacks has quit [Quit: Quitter]
lynxeye has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
flacks has joined #dri-devel
frieder has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
flto_ has quit []
flto has joined #dri-devel
<hakzsam>
jekstrand: any reasons why OpAtomicISub is emitted as atomic_add+ineg? same question for inc/dec. Note that AMD has instructions for them, so maybe we could introduce atomic sub/inc/dec and lower for hw that don't support them?
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
camus has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
adjtm has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
rsalvaterra has joined #dri-devel
flto has joined #dri-devel
itoral has quit [Remote host closed the connection]
dolphin has quit [Quit: Coyote finally caught me]
Bennett has joined #dri-devel
frieder_ has joined #dri-devel
frieder has quit [Read error: Connection reset by peer]
<jekstrand>
hakzsam: First off, I think the canonicalization helps with optimization. If you did have atomic_sub, you'd want to switch to it late to remove the neg, not use it right away in case someone was doing atomic_sub(p, -x).
<jekstrand>
hakzsam: Also, the assumption is the atomic is massivly more expensive than the ineg so why bother
<jekstrand>
But we could have an optimization for it.
<jekstrand>
As for inc/dec, we figured that you can detect atomic_add(p, -1) easily enough in the back-end that it wasn't worth the bother. We do in our back-end compiler.
vivijim has joined #dri-devel
<jekstrand>
But if someone wanted to make that a NIR pass, I guess I wouldn't be opposed.
<hakzsam>
yeah, it can also be done in ACO and seems actually simpler that adding new intrinsics all over :)
<jekstrand>
:)
<jekstrand>
Yeah, adding new atomic intrinsics is such a pain...
<hakzsam>
quite
<HdkR>
Need an atomic_not IR op so llvmpipe can emit optimal atomic not on x86 ;)
<HdkR>
oop, messed up. s/not/neg/g
pochu has quit [Ping timeout: 480 seconds]
hanetzer1 has quit []
sdutt has joined #dri-devel
<dschuermann>
hakzsam: the AMD inc/dec have conditional semantics and don't exactly match the SPIR-V semantics
<mriesch>
danvet: i disabled the framebuffer emulation as you suggested and tried to set a mode with modetest. but i think the underlying problem still remains and no modesets are reported by the encoder
<mriesch>
i traced it down a bit and it seems that the encoder is not enabled to begin with. who or what should enable the encoder?
alyssa has joined #dri-devel
* alyssa
studies GenXML
hanetzer has joined #dri-devel
<jekstrand>
cwabbott: One potential bug and 3 nits. Otherwise, first two look good, I think.
<alyssa>
@intel people - For significant chunks of per-gen code that is the same for all versions before X and for all versions after X, does it make sense to special case only compiling it twice instead of for every single gen and having tons of duplicated symbols?
<mriesch>
ok, to be precise we were talking about connectors before. the connector is present, but the helper .get_modes is never called. so i think i am asking which entity should call it at which point
<pq>
3 nits is pretty dim. *badabum tshhh*
<alyssa>
I'm worried about regressing driver code size from duplicating everything 5x all of a sudden
<alyssa>
also worried about compile
<emersion>
you're the only one in the room who knows about colorimetry, pq!
<cwabbott>
jekstrand: i just checked and all the _imm builder helpers use uint64_t
<pq>
emersion, aaha! Evidently I'm not. :-D
<jekstrand>
cwabbott: Really?
<cwabbott>
yup
<jekstrand>
Ok, then. Ignore that.
<jekstrand>
I thought through it at one point in time and made a careful choice based on C sign extension rules. Let's keep consistent with past me.
<cwabbott>
nir_iadd_imm, nir_isub_imm, nir_imul_imm, nir_imm_intN_t do at least
<jekstrand>
Yup
<cwabbott>
jekstrand: damn, making me put on my thinking cap :)
<jekstrand>
?
<cwabbott>
with your bug
<cwabbott>
this whole mask thing is just really really fiddly
<cwabbott>
jekstrand: ok, updated again
<jekstrand>
Yeah
<jekstrand>
It si
<jekstrand>
is
<jekstrand>
cwabbott: sure it's lt and not le?
<jekstrand>
Oh, wait... you flipped arguments around. Gotta think
<cwabbott>
yeah, there's no nir_ugt
<cwabbott>
maybe we should have that as a builder thing
<jekstrand>
One of the few reasons I wish NIR was C++: We could make builder helpers take immediates and SSA defs in the same argument.
mbrost has joined #dri-devel
<jekstrand>
cwabbott: Yeah, having builder things for those would be nice
<alyssa>
jekstrand: Please read some LLVM source code and reconsider your wishes 😋
<jekstrand>
alyssa: I did say "few"
<alyssa>
😉
<alyssa>
One of the many reasons I wish NIR were Rust...
<alyssa>
("Please read 'Learning Rust With Entirely Too Many Linked Lists' and reconsider")
<jekstrand>
I've read that post.
<HdkR>
C11 has a...fun way to do function overloading with _Generic
<alyssa>
0000000000000000 R panfrost_pipe_format_7
<alyssa>
it's right there! :<
<alyssa>
.....oh i missed a v
* alyssa
shows herself out
<ccr>
just today I was staring at a piece of Perl code that had a syntax error and it took several minutes to "see" that I had written ~= instead of =~
<jenatali>
Clang and GCC support attribute((overloadable)) in C, but MSVC doesn't have an equivalent unfortunately
<JoshuaAshton>
MSVC has no stdatomic.h either :(
<JoshuaAshton>
We have to roll our own really cursed atomic impl in vkd3d-proton
<jekstrand>
This is why people should use clang on Windows. :P
<tango_>
we need a language haflway between C and C++
<JoshuaAshton>
Maybe Microsoft should ship that by default and make it default then :frog:
<HdkR>
ooo, __attribute__((overloadable)) is cute
<JoshuaAshton>
LTO (LTCG) is still entirely broken in MSVC and produces complete garbage on any project you through at it :-/
<tango_>
was overloadable introduced with opencl support in clang?
<tango_>
because opencl c has lots of overloaded functions
<jekstrand>
__attribute__((overloadable)) is how it's done for OpenCL C, yes.
<jekstrand>
If jenatali would have just implemented CLOn12 using MSVC as the front-end, we might have these nice toys. :-P
<jekstrand>
Who am I kidding? They would have implemented it for OpenCL C and then still not allowed it with regular C.
<jenatali>
I don't even want to think about that...
<alyssa>
tango_: C+
<jenatali>
JoshuaAshton: We use LTCG for D3D, and I haven't heard of any problems with getting garbage out
<JoshuaAshton>
You must be very very lucky, I have had a success rate of 0
<alyssa>
tango_: incidentally, the maximal grade of any CS assignment written using it
<tango_>
8-D
<JoshuaAshton>
same goes with a bunch of my other game dev friends
<jenatali>
Weird, what kinds of garbage?
<tango_>
the real question is which parts to choose. I'm not even sure what your complaints about LLVM's usage of C++ was, for example
<jenatali>
Like, inefficient garbage? Or incorrect garbage?
<JoshuaAshton>
incorrect
<tango_>
(that was for alyssa)
<JoshuaAshton>
If I enable LTCG in one of my projects, for some reason the mouse gets trapped in the centre of the screen and I can't look around ingame anymore
<jenatali>
Was that recent? If so, absolutely file feedback on that, the compiler teams take that pretty seriously
<JoshuaAshton>
It's been around for yeeears
<alyssa>
tango_: oh that was just a dig at llvm's aesthetics
<tango_>
alyssa: I must confess I've never looked at its internals. I'm just happy it compiles our cuda code producing 3x faster kernels
<ccr>
always better not to look behind the curtain
<tango_>
if that comes at the cost of the llvm source code itself being the most horrible code ever written, I'm OK with that
<tango_>
ccr: then again, our code would probably offend alyssa's sense of taste too
<alyssa>
almost certainly
<jekstrand>
LLVM certainly isn't the most horrible code ever written (have you looked at dEQP?) and there are definitely some gems in there, but it can be pretty intractable in places too.
<alyssa>
examples of good code to me:
<alyssa>
- most of NIR
<alyssa>
- anything written by anholt
<alyssa>
- that's it tbh
<tango_>
alyssa: it's all C++ with several layers of indirections, conditional inheritans and enable_ifs ALL AROUND
<jekstrand>
alyssa: Don't look at our vec4 compiler if you want to keep that 2nd one intact. :)
<tango_>
inheritance, too
<alyssa>
jekstrand: Heh
<HdkR>
Don't need enable_if with C++20 concepts. Instead you get require require ;)
<tango_>
HdkR: lol
<tango_>
HdkR: our C++ standard choice is dictated by nvidia
<tango_>
we only migrated to C++11 like two years ago
* jekstrand
barely even knows last decade's C++, much less this modern stuff.
<tango_>
alyssa: but some things would have been much easier to write in C++
<jekstrand>
alyssa: If I had those principles, you wouldn't like my code. :P
<alyssa>
jekstrand: 👶
<JoshuaAshton>
I want to like C but I get bit by so many type safety issues that really make me go Grrrr
<JoshuaAshton>
I want typesafe flags
<JoshuaAshton>
and other nice things
<tango_>
wait you can have constexpr constructors?
<jenatali>
Same
<JoshuaAshton>
We were bit by a typesafe flag bug today in vkd3d-proton and I am sad there is no compiler extension for this
<jenatali>
tango_: Yeah you can do pretty much anything constexpr if you go new enough. Even dynamic memory management (as long as it's trivial)
<tango_>
woah
<alyssa>
GenXML question -- how do you handle common enums in common code?
<jekstrand>
Every time I think C++ gives me type safety, shortly thereafter I try to make some data structure const-correct, pull my hair out, and go back to ignoring it and writing C.
<jekstrand>
alyssa: What do you mean?
<alyssa>
(Common across hw generations)
<JoshuaAshton>
I have never had problems with const-correctness really
<JoshuaAshton>
even C has const correctness so :shrug:
<JoshuaAshton>
just not as strict...
<alyssa>
A function like "map_pipe_format_to_zs_format" returning an enum hw_zs_format, where hw_zs_format is identical across every generation
<jekstrand>
C has const. It doesn't have any correctness. :P
<JoshuaAshton>
yes :frog:
<alyssa>
Does that have to be duplicated for every gen just because hw_zs_format is defined separately in every xml?
<tango_>
JoshuaAshton: interesting use of static_assert instead of enable_if for the constructor on line 20
<jekstrand>
const-correctness is mostly possible in C++. It just means thinking very hard and typing everything (including all bugs!) at least twice.
<jekstrand>
alyssa: Yes
<JoshuaAshton>
tango_ I am not familiar with enable_if which is why I didn;t use it
<JoshuaAshton>
How would I take advantage of that there?
<jekstrand>
alyssa: That's why we have things like our format enum elsewhere.
<alyssa>
jekstrand: Hm.
<tango_>
JoshuaAshton: enable_if was I think the first C++11 feature I learned. but in constructors it's a PITN to use
<JoshuaAshton>
Oh interesting
<JoshuaAshton>
I see now
<tango_>
JoshuaAshton: so I'm sure that whatever alternative would be aesthetically less pleasing than what you have there
<tango_>
JoshuaAshton: enable_if is a godsend if you don't have if constexpr and you want to do template specialization based on partial matching of template argument feature
<JoshuaAshton>
Enable if might be better though as it wouldn't trigger the constructor in that case?
Ahuj has quit [Ping timeout: 480 seconds]
<tango_>
JoshuaAshton: you're still catching it at compile time, the only difference is what kind of error you get
<JoshuaAshton>
true...
* alyssa
is super overwhelmed trying to untangle this code
<tango_>
JoshuaAshton: with static_assert you get a nice message to your liking, with enable_if you only get errors about constructors not being found
<tango_>
which is best ... dunno
<tango_>
alyssa: it would be so much easier if it was C++ ...
<tango_>
(;-))
<alyssa>
tango_: No, it wouldn't.
<tango_>
alyssa: I know, I'm joking
<jenatali>
tango_: enable_if is good for having 2 implementations of things without constexpr if, not for hiding things in bad cases - static_assert is much better for that
<tango_>
JoshuaAshton: you know, I might actually steal this static_assert idea of yours
ramaling_ has joined #dri-devel
ramaling_ has quit []
<tango_>
jenatali: yeah
<JoshuaAshton>
nice
<tango_>
jenatali: we use enable_if to do partial function template specialization
<JoshuaAshton>
also for some reason that dot product produces much better code than just doing a.x * b.x + a.y * b.y + a.z * b.z
<JoshuaAshton>
why? who knows!
<JoshuaAshton>
on clang its the same
* tango_
is still at the constructors
<JoshuaAshton>
on GCC and MSVC it's much better
<tango_>
JoshuaAshton: what do you mean by better?
<jenatali>
Yeah. I wrote a large mess that implements our entire D3D driver layer by template-generating passthrough functions based on pattern matching function signatures. I'm familiar with enable_if and partial specializations :P
<JoshuaAshton>
4 instruction sshorter :frog:
alyssa has quit [Quit: leaving]
ramaling_ has joined #dri-devel
<cwabbott>
JoshuaAshton: "The old optimizer is extremely sensitive to changes, and getting a fix into 16.11 with a point-fix for this issue would cause additional churn which puts much other code at risk." <- I wonder what lovecraftian horror their old code is that they can't even be confident in bug fixes
<tango_>
JoshuaAshton: fma?
ramaling_ has quit []
<JoshuaAshton>
tango_: What about fma?
<tango_>
JoshuaAshton: does your dot implementation produce more compact code because it uses fma more aggressively?
<tango_>
ok there's only 3 things I don't like about your code: length, normalize and the stream output function
<tango_>
everything else is lovely
<JoshuaAshton>
Yeah, I'm sorry about the float cast :(
<JoshuaAshton>
There is always a chance the length can be fractional so I will probably take the floating point type that fits the best
<JoshuaAshton>
ie. float or double :p
<JoshuaAshton>
there is lengthSqr if you wanna just get it as the type you put in and deal with it yourself
<JoshuaAshton>
normalize could probably use length square
<JoshuaAshton>
wait hm
<JoshuaAshton>
yeah or something idk, I'll look at it when I touch this silly sideproject again when travelling :)
camus1 has joined #dri-devel
<tango_>
JoshuaAshton: my objecting to length is that it does * (1.0f/length) instead of just /length. I know why, but I prefer more accurate things
sdutt has quit []
<tango_>
JoshuaAshton: otoh you could do things for more accuracy with a different signature, like using hypot for the accurate length
<tango_>
(of course you'd have to implement hypot in the first place)
<JoshuaAshton>
std hypot :)
sdutt has joined #dri-devel
<JoshuaAshton>
but ye
camus has quit [Ping timeout: 480 seconds]
<tango_>
JoshuaAshton: not std hypot of course, you'd have to implement one specific for your types 8-)
<JoshuaAshton>
I have learnt not to really trust the std math functions ever
<JoshuaAshton>
std::lerp is a fucking joke
<JoshuaAshton>
especially the MSVC impl
<tango_>
std::abs all components, sort by magnitude in decreasing order, divide by the first, sqrt of the dot product of this, and multiply by the largest
<tango_>
should be trivial to implement with transforms 8-)
<tango_>
but you stil need a traits structure to tell you what type to use for length
<tango_>
or just use double or make it a template parameter defaulting to double
<JoshuaAshton>
ehhh, double default pooey, I'd probably take sizeof(T) and choose based on that by default
<tango_>
I mean for hypot it makes sense
<tango_>
you don't use hypot if you don't want accuracy, because hypot sucks performance-wise
frieder_ has quit [Read error: Connection reset by peer]
frieder has joined #dri-devel
aravind has quit []
frieder has quit [Remote host closed the connection]
GloriousEggroll has joined #dri-devel
loki_val has quit []
crabbedhaloablut has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
tobiasjakobi has joined #dri-devel
gouchi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
ngcortes has quit []
ngcortes has joined #dri-devel
<mriesch>
danvet: turns out the connector does not report the HDMI HPD status correctly. i'll withdraw my question ;-)
<danvet>
mriesch, yeah that's all covered with the helpers, it's split into detect and probe iirc
lemonzest has quit [Quit: Quitting]
<mriesch>
danvet: OK, thanks. the main issue is the hotplug detection in the rk3568 HDMI driver then. maybe the IP version in this chip needs something extra
<danvet>
mriesch, double-check your cable/monitor with another chip first
<danvet>
sometimes the hpd just doesn't work ime
lynxeye has quit []
<mriesch>
danvet: good point, will check that.
tzimmermann has quit [Quit: Leaving]
mbrost has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
<enunes>
hi all, I have been doing some work to enable CI for lima again. I created a lava setup with a few boards following https://docs.mesa3d.org/ci/LAVA.html and I think it is ready for some initial tests now. who can help me with the next steps?
<enunes>
anholt maybe ?
pnowack has quit [Quit: pnowack]
mbrost has quit [Read error: Connection reset by peer]
iive has quit [Read error: Connection timed out]
xexaxo_ has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
camus1 has joined #dri-devel
LaserEyess has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
pnowack has joined #dri-devel
mixfix41_ has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
mixfix41 has quit [Ping timeout: 481 seconds]
<agd5f>
mriesch, some board vendors may not wire up the pins correctly as well.
<mriesch>
agd5f: hmm... i'll have a look at that as well
<anholt>
enunes: if you mean the runner registration, I'm gone for a few days so maybe hit up daniels or bentiss for registration token and sanity checking your runnerrs.
tarceri_ has quit [Remote host closed the connection]
* jekstrand
assigns "Drop Android.mk" to marge
<jekstrand>
It's got 6 👍, 3 🎉, and an ack.
<daniels>
enunes: o/
<daniels>
nice to see it!
<daniels>
jekstrand: it has every positive emoji from me as well
<jekstrand>
:D
mlankhorst has quit [Ping timeout: 480 seconds]
<daniels>
^ including that
<bl4ckb0ne>
nice diff
<jekstrand>
bl4ckb0ne: For better or worse, that won't make a dent in my stats. :-/
<bl4ckb0ne>
anyway it deserves a little rocket emoji
<jekstrand>
Feel free to give it one. :)
<jekstrand>
Oh, so you did. :D
<bl4ckb0ne>
:)
<enunes>
daniels anholt awesome, thank you! so I would like some additional feedback before actually adding it
<daniels>
enunes: do yo uhave a MR link?
<enunes>
so my setup has a network with the lava master, a separate arm64 node that is what I intend to register as the runner, and 3 boards to be controlled by that runner
<enunes>
should I do it like that with 1 runner and parallel: 3 ?
<jekstrand>
Goodbye, Android.mk and good riddance!
<enunes>
I would also need meson-gxl-s805x-libretech-ac.dtb available in the CI archives, so I believe I need to change that tag to force a new container image to be generated?
<enunes>
and the tag I would add to the runner is mesa-ci-aarch64-lava-lima
<daniels>
enunes: correct you do, and I would also make it parallel 4 just so you can parallelise container/artifact transfer against LAVA execution
<daniels>
you can add tags with the gitlab-runner registration
<daniels>
is $DEQP_PARALLEL right for your board? you want to have it at roughly the number of cores available per-device, but if they have low memory, capped at whatever number stops you from OOMing
Daanct12 has joined #dri-devel
<enunes>
hm I didn't look much into that one, these boards dont have that much memory so maybe 1-2 would be better there
<daniels>
well yeah, whatever the highest number is which will get them through without banging into the OOM killer :)
Danct12 has quit [Ping timeout: 480 seconds]
<enunes>
I see in the scripts and existing lava jobs there is a lot of handling for caching things locally, is it ok if I dont have that?
<daniels>
enunes: sure, that's fine - it used to be pretty critical for reducing transfer, but these days it's a time optimisation for not pulling large rootfs over the Atlantic multiple times
<daniels>
I can share our nginx config with you if you like; it's a pretty trivial caching proxy
<enunes>
alright good to know, I think for now I will skip that, with my tests so far it has been only a few seconds to download the images
mbrost has joined #dri-devel
<daniels>
yeah, that doesn't seem like a bottleneck tbh :)
Duke`` has quit [Ping timeout: 480 seconds]
Guest237 has joined #dri-devel
<jekstrand>
krh: Thought you wouldn't care to know that, aparently, there are less than 3k lines of your code left in src/intel
* jekstrand
is running git blame stats just for giggles.
Guest237 has quit [Remote host closed the connection]
<daniels>
enunes: np, great to see it back! I've flipped notifications on for it, but do please ping me when you're confident with it and ready for review :)
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
pnowack has quit [Quit: pnowack]
mbrost has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
Bennett has quit [Remote host closed the connection]
iive has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
danvet has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
alyssa has joined #dri-devel
mbrost has joined #dri-devel
pcercuei has quit [Quit: dodo]
mbrost has quit [Read error: Connection reset by peer]
anujp has joined #dri-devel
pochu has joined #dri-devel
mbrost has joined #dri-devel
camus1 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
camus has quit [Read error: Connection reset by peer]
iive has quit []
lcn has quit [Remote host closed the connection]
macromorgan_ has joined #dri-devel
macromorgan has quit [Remote host closed the connection]