<karolherbst>
why is basic arraycopy failing.. mhh
<karolherbst>
yeah okay, so that copies from one to another buffer and reads the result out.. yeah ehh.. why does that fail
<zmike>
daniels: oh ok that's much more reasonable then
<zmike>
as we all know, a630 is expected to fail, so when it does, that's just part of life
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
iive has quit []
<karolherbst>
jekstrand: huh.. does basic arraycopy work on your end?
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
no idea what's up with that test, but the first one copies from a USE_HOST_PTR buffer into a plain one and somewhere there the data gets lost :(
<karolherbst>
I hope I didn't mess up offsets again
apinheiro has quit [Quit: Leaving]
mbrost_ has quit [Ping timeout: 480 seconds]
<airlied>
jekstrand: maybe doing aco is easier than trying to work out images with llvm :-P
* karolherbst
scratches his head
<karolherbst>
so it does work with CL_MEM_COPY_HOST_PTR at least... so probably something to do with userptr support... mhh
<karolherbst>
wait... it's doing weird things
h0tc0d3 has quit [Quit: Leaving]
h0tc0d3 has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
gawin has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
devilhorns has left #dri-devel [#dri-devel]
ybogdano has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: remember why clover would be doing a buffer mapping on a texture resource?
<airlied>
is that one of those things drivers are meant to allow
HankB__ has quit [Remote host closed the connection]
HankB__ has joined #dri-devel
ngcortes has joined #dri-devel
MrCooper_ has joined #dri-devel
MrCooper has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
DanaG has joined #dri-devel
heat has joined #dri-devel
h0tc0d3 has quit [Remote host closed the connection]
<karolherbst>
airlied: no idea
h0tc0d3 has joined #dri-devel
<DanaG>
I still remember a time when I broke Nouveau on a GeForce Go 7600 by removing the laptop panel from a laptop, because it was dead and huge and in the way.
<DanaG>
Apparently at the time, there was code that assumed that if there's LVDS, it must be connected. Was a trivial fix.
<DanaG>
(I'm not the one who fixed it.)
alyssa has quit [Quit: leaving]
<airlied>
karolherbst, jekstrand : so the abi makes doing images the way clover does it now really hard
<airlied>
I think it probably wants to either shove a ptr to descriptor or a full descriptor into the kernel argument list
ngcortes has quit [Ping timeout: 480 seconds]
Akari` has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
* airlied
gets to the same abi problem every time with radeonsi compute images, and it blocks me
<airlied>
I guess aco is the better plan
mhenning has quit [Quit: mhenning]
fxkamd has quit []
shashank_sharma has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
sdutt has quit [Remote host closed the connection]
agd5f has quit [Remote host closed the connection]
sdutt has joined #dri-devel
mbrost has quit [Remote host closed the connection]
agd5f has joined #dri-devel
tales_ has quit [Remote host closed the connection]
tales_ has joined #dri-devel
jewins has quit [Remote host closed the connection]
jewins has joined #dri-devel
aswar002 has quit [Quit: No Ping reply in 180 seconds.]
rsripada has quit [Remote host closed the connection]
Znullptr has joined #dri-devel
shashanks has joined #dri-devel
aswar002 has joined #dri-devel
ZeZu has quit [Read error: Connection reset by peer]
rsripada has joined #dri-devel
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
shashank_sharma has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
eukara has quit []
khfeng has quit [Quit: Konversation terminated!]
khfeng has joined #dri-devel
eukara has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
mdroper has quit [Read error: Connection reset by peer]
danvet has joined #dri-devel
sumoon_ has joined #dri-devel
sumoon_ has quit [Remote host closed the connection]
tales_ has quit [Remote host closed the connection]
shankaru has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
mwk has quit [Ping timeout: 480 seconds]
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
mwk has joined #dri-devel
Duke`` has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
sadlerap has quit [Remote host closed the connection]
sadlerap has joined #dri-devel
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
SR_71 has joined #dri-devel
flacks has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
<dolphin>
airlied: sent the drm-intel-fixes PR already today, easter holidays will cause a lot of OoO next 1.5 weeks
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
mszyprow has joined #dri-devel
maxzor has joined #dri-devel
mvlad has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
<tomeu>
looks like anholt's lab is down
<tomeu>
will disable it
jkrzyszt has joined #dri-devel
camus has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
paulk1 has joined #dri-devel
camus has quit []
macromorgan is now known as Guest1820
Guest1820 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
<danvet>
javierm, if you have time for a quick review "fbcon: Fix delayed takeover locking"
* danvet
heading out tomorrow morning for long easter w/e
rasterman has joined #dri-devel
dliviu has joined #dri-devel
aravind has joined #dri-devel
<javierm>
danvet: sure, let me look at the patch now
<danvet>
karolherbst, I'm assuming you're pushing your dma-buf-map patch to drm-misc yourself?
mceier has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<javierm>
danvet: it wasn't quick because had to read ind detail again the fbdev code to remember how the console_lock and deferred fbcon takeover worked :)
<javierm>
danvet: if guess that should work then if nathan tries with fbcon=nodefer
<danvet>
javierm, well it took me a while to page it all in again too
<javierm>
danvet: yeah, the locking there is quite complex
<danvet>
I'll wait for hopefully a t-b from nathan and then push this afternoon
<javierm>
I think that breaks one of the most important locking rules, protect data not code
<danvet>
javierm, thx for the review
<danvet>
javierm, yeah console_lock is 100% protect code, not data
<danvet>
and it's terrible
<javierm>
yeah
<javierm>
danvet: IMO your patch has merit on its own even if nathan can't give his t-b
mszyprow has quit [Ping timeout: 480 seconds]
<javierm>
danvet: there's clearly a deadlock there and your patches fixes it so not sure that makes sense to wait until your are back from your easter holidays
<javierm>
*patch
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
rkanwal has joined #dri-devel
simon-perretta-img has quit [Quit: Leaving]
mszyprow has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
<karolherbst>
danvet: yeah
<karolherbst>
danvet: the only thing I am not sure of is if "people might start use the old header" is reason enough to put it into -fixes
<karolherbst>
I guess it is, but would like to make sure before
<danvet>
karolherbst, it's not uapi, so we just need to keep whacking this I guess
<danvet>
and yeah since it's in -rc1 maybe put it into -fixes to kill it for good hopefully
probablymoony has joined #dri-devel
itoral has quit []
<karolherbst>
okay, then I am going push it today to fixes
moony has quit [Read error: Connection reset by peer]
<karolherbst>
jekstrand: so uhm.. there is something I found: resource_copy_region doesn't seem to work reliably if one of the pipe_resources is backed by a user pointer
<karolherbst>
not sure what gallium itself allows me to do here
<karolherbst>
or well.. what's expected to work
<zmike>
seems like that should work if it's a buffer
<karolherbst>
yeah well.. it doens't with iris
<karolherbst>
I think my code is fine, because doing pipe_transfer + memcpy instead does work
<karolherbst>
I am sure all those user pointer paths are probably not that well tested
<emersion>
yeah i've seen some of the patches going through :)
<swick>
jani: I wondered if the kernel could share some code with user space
<swick>
but I'm not really optimistic about it
<jani>
emersion: the TL;DR, it's a really bad idea to pass around pointers to variable size blob data originating from outside the kernel
<swick>
and then I wondered if it is possible to remove the EDID code in the kernel altogether
<jani>
emersion: it's also a really bad idea to parse that data all over the place
<emersion>
by "outside the kernel" you mean… EDID override? or just bad monitors?
<emersion>
yeah, we're def not doing the latter in our lib
<swick>
hotplug invalidating the pointers?
<jani>
emersion: basically displays and broken edid reading code all over the place. you might have only 128 or 256 bytes allocated for the edid, but no checks that the extension count agrees with that. then you pass around pointers to that edid, and the edid itself is the only information about the size of the allocated block
<emersion>
makes sense
<jani>
swick: I'm really pessimistic about sharing code between kernel and userspace, especially since it turned out it's too hard to share code between two userspace edid parsing projects :p
<emersion>
lol
<jani>
maybe more likely would be to not parse in kernel at all, but I don't know how that would pan out. we do need the info in kernel, I don't know how to offload that to userspace
<jani>
basically I've settled to dreaming of building the kernel edid parser in userspace for unit testing and fuzzing only
<vsyrjala>
afaik the kernel can embed a userspace binary and just call that. but having tons of entrypoints into the edid parser probably isn't very feasible with that
<vsyrjala>
ie. would probably need to pass more or less all the parsed data back via some display_info type structure
<jani>
emersion: oh, and wrt the memory allocated to the edid, the hf-eeodb was really a blow under the belt. basically an edid extension to override the extension block count
<emersion>
ahahah yeah i saw that
<emersion>
"clever" as one would say
<emersion>
(missing a few dozen quotes around that word)
<jani>
and with just struct edid *, there's no way to attach meta info about it anywhere, because it's blob data
<jani>
back to the original bad idea
<jani>
vsyrjala: that's interesting. can you point me at examples of it in kernel? I guess it would be theoretically possible after I've got the struct drm_edid encapsulation done, and we've hidden all the details in drm_edid.c
LexSfX has quit [Remote host closed the connection]
LexSfX has joined #dri-devel
LexSfX has quit [Remote host closed the connection]
LexSfX has joined #dri-devel
<vsyrjala>
forgot where it was already. but looks like kernel/usermode_driver.c is the stuff i was thinking about
<swick>
vsyrjala: yeah, passing in the data the kernel actually needs is exactly what I was thinking
<karolherbst>
zmike: yeah, it does
<swick>
there actually isn't that much the kernel wants from the EDID
<zmike>
karolherbst: so probably a gpu sync issue
<karolherbst>
yeah.. let me wait on a fence and see what happens
<karolherbst>
mhh, so flushing + wait doesn't fix it
<karolherbst>
maybe a barrier?
<karolherbst>
yeah.. no idea.. something doesn't work at all there
<jani>
swick: you think so?
<swick>
jani: did I miss something?
<jani>
swick: parsing of all the modes, color formats, color depths, tile info (from displayid blocks), hdr metadata, audio info, ...
<swick>
why hdr metadata?
<swick>
the prop is attached if the GPU supports the infoframe and user space is responsible for figuring out if it can be used
<jani>
I guess for infoframe packing, idk
<swick>
but yeah, the audio stuff I missed
<swick>
anyway, I still think removing the EDID code would be a good idea and having parsing at a central place makes that easier so, yay, good work!
<jani>
:)
alyssa has joined #dri-devel
ahajda has joined #dri-devel
nashpa has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
SR_71 has quit [Ping timeout: 480 seconds]
SR_71 has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
Company has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
sdutt has joined #dri-devel
jewins has joined #dri-devel
<karolherbst>
zmike: ehh... it was my fault afterall :)
<karolherbst>
mhhh, maybe not, as that one test still fails
karolherbst_ has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
shankaru has quit [Quit: Leaving.]
fxkamd has joined #dri-devel
thellstrom has quit [Quit: thellstrom]
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
jkrzyszt has quit [Ping timeout: 480 seconds]
shankaru has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
frieder has quit [Remote host closed the connection]
maxzor has joined #dri-devel
mbrost has joined #dri-devel
<jekstrand>
kusma, bbrezillon: How bad is the C/C++ mismatch in Vulkan common code?
<jekstrand>
I've tried to keep it C++-safe but dozen is the first driver to actually exercise that. :-/
<kusma>
jekstrand: It's not great... I think the biggest problem is that designated initializers makes us depend on C++20, which is a bit of a mess both with Meson and MSVC...
<karolherbst_>
jekstrand: shadow buffers are a pita :(
karolherbst_ is now known as karolherbst
<kusma>
But there's a bunch of tiny papercuts. Modern C and C++ just... aren't friends.
<kusma>
jekstrand: So we're changing that, by moving Dozen to C.
<karolherbst>
it's still beyond me why C++ wasn't designed as a super set of C :(
<jekstrand>
kusma: Yeah... I saw the MR and it made me a tiny bit sad.
mceier has joined #dri-devel
<jekstrand>
Not really sad to see less C++ in Mesa. I don't like C++. More sad that it's necessary. I wish C++ and C11 could get along better.
<kusma>
jekstrand: Yeah, I wish so too. But I sadly think the facts of reality means we need this...
MrCooper_ is now known as MrCooper
<karolherbst>
mhh I need util/u_range.h in rusticl :(
<karolherbst>
ehh wait.. that doesn't even cut it
<kusma>
I think the root cause of the issue here is really that the C++ committee doesn't seem to care about C++ as anything else than an application programming language. The absolute ABI-mess that libc++ causes means we can't really use it. And modern C++ without libc++ is kinda... broken.
<karolherbst>
so libstdc++ is broken?
<karolherbst>
:)
<kusma>
Not broken, if you look at it from an application point of view.
<karolherbst>
sure
<kusma>
But depending on something that depends on libc++ is a recipe for disaster.
<karolherbst>
I just meant that we have like two versions and they don't mix well... c++11 was just such a mess overall
jkrzyszt has joined #dri-devel
<karolherbst>
well on the other hand you have like 1000 list implementations in C
<karolherbst>
not sure what's better
ppascher has quit [Ping timeout: 480 seconds]
<kusma>
Yeah, not saying that's great either.
<karolherbst>
I hope rust won't become a mess in that regards :)
<kusma>
Yeah... I'm still on the fence about rust in libraries... Seems to have worked OK for librsvg so far, but we don't know what's on the horizon.
<karolherbst>
well...
<kusma>
I suspect that some of the problems C++ have here over C is really just that C++ is moving fast, and C is moving slow (but very carefully)...
<karolherbst>
but yeah.. I guess libs being a pure rust thing and used by other C libs is something different than just implementing some C API in rust
<Thaodan>
I see a hard dependency on llvm as an issue, previously stuff was changed to make it not depend on GCC and not it is going the other way around.
<karolherbst>
kusma: although is it compareable? C++ adds tons of stuff into stdlib, but like actualy core language features?
<karolherbst>
C++ usually just adds dubious stuff as core lang features
<karolherbst>
like I am still not convinced that if constexpr was a good idea at all
nchery has quit [Read error: Connection reset by peer]
<kusma>
karolherbst: Depends on what you consider core language features. Stuff like std::construct_at for instance might be a fairly important thing for modern C++...
<karolherbst>
kusma: if it's implemented in the compiler
<karolherbst>
if you can write a header to use that in older C++ then it's not a core feature
<kusma>
karolherbst: Well, the thing is that a lot of modern libc++ stuff complements compiler-features, to the point where they are almost useless without them...
<karolherbst>
sure and that's fine
<karolherbst>
but you could also do that in external libs like what Rust prefers to do
<karolherbst>
like rusts futures are also almost pointless on their own
<karolherbst>
need crates to actually make good use of them
<kusma>
I think what I'm trying to say is that modern C++ minus libc++.... is really a different language.
<karolherbst>
true
<kusma>
Yeah, you might be able to write some code that works with it. But you end up doing a lot of non-idiomatic stuff.
<karolherbst>
I think what I tried to say is, that C usually just focus on core features and lets libraries to come up with good things. Like C in the gnome world is also totally different C than "plain C".
<karolherbst>
what if C had a strong stdlib and it would have been glib
<karolherbst>
anyway, it's easy to move faster if you can just push stuff into header files people use and not have to deal with patching compilers
sdutt has quit []
sdutt has joined #dri-devel
h0tc0d3 has quit [Quit: Leaving]
<karolherbst>
map/unmap is just so broken in CL :(
paulk1 has joined #dri-devel
Duke`` has joined #dri-devel
h0tc0d3 has joined #dri-devel
nchery has joined #dri-devel
<mdnavare>
vsyrjala: For the drm_atomic_check_only warning regarding mismatch in requested and affected CRTC , can we remove this check entirely?
aravind has joined #dri-devel
tales_ has joined #dri-devel
<zmike>
eric_engestrom: how long before branchpoint?
jkrzyszt has quit [Ping timeout: 480 seconds]
<eric_engestrom>
zmike: dcbaker is handling 22.1 :)
<zmike>
oh oops
<zmike>
cc dcbaker then
mbrost has quit [Ping timeout: 480 seconds]
* jekstrand
wishes RENDER_SURFACE_STATE::Pitch could be 0 :(
aravind has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<dcbaker>
zmike: is there something you're hoping to get in before I branch?
<zmike>
yes
<zmike>
dcbaker: !15928 is in the process of going in
<zmike>
zink is (more) broken without it
<dcbaker>
zmike: I’ll wait, I’ve also got a 22.0 release to make today
<zmike>
awesome, thanks
<alyssa>
dcbaker: apparently i'm supposed to review the nir vectorizer changes so they can go in for the bpoint
gouchi has joined #dri-devel
alyssa has quit [Quit: leaving]
lemonzest has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
ybogdano has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
iive has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
julian has joined #dri-devel
julian has left #dri-devel [#dri-devel]
jorth has joined #dri-devel
<dcbaker>
zmike, @alyssa I'll plan to branch around 15:00 PDT unless you all let me know to push it out further
<zmike>
alternatively if it hasn't you could just preemptively pick it I suppose?
<karolherbst>
jekstrand: soo.. I think shadow buffers are working out alright now :) I tried with always failing _from_user_memory and it doesn't cause any regressions
<karolherbst>
the implementation isn't perfect though and I still want to restrict syncing only mapped regions, but that has to wait
lynxeye has quit [Quit: Leaving.]
macromorgan has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
new panfrost maintainer policy: everytime someone asks me to do something, i write docs that tell them how to do it
<alyssa>
how long will this last you think? :-p
<kisak>
until the first question
tzimmermann has joined #dri-devel
mbrost has joined #dri-devel
<alyssa>
rude
<alyssa>
accurate, but rude
<alyssa>
:-p
rcf has quit [Quit: WeeChat 3.6-dev]
<jekstrand>
karolherbst: Ok, I think I have clear_buffer implemented "for real"
<karolherbst>
yay
<jekstrand>
karolherbst: What's the best set of tests for it?
mszyprow has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: there are a set of buffers buffer_fill_* tests
<karolherbst>
* replaced by each type
<alyssa>
jekstrand: out of interest what impl for clear_buffer?
* alyssa
isn't actually sure what the fastest way to clear_buffer on mali is
<jekstrand>
alyssa: It's required by CL
<jekstrand>
alyssa: I'm implementing it for iris
<alyssa>
ah
<alyssa>
probably a compute shader for us?
<karolherbst>
alyssa: that's what I am thinking about to do as a fallback in rusticl
<alyssa>
but then again, maybe mapping the buffer as R32_UINT framebuffer and clearing might be faster, since it skips the shader cores?
ngcortes has joined #dri-devel
<alyssa>
probably not but might be a fun benchmark
<karolherbst>
yeah... so.. there is one thing which is annoying
<alyssa>
alignment?
<jekstrand>
There's always the stupid simple impl of map the buffer and memcpy on the CPU
<karolherbst>
drivers might be able to speed up _some_ clear_buffer ops, but have to fallback to pure sw for others
heat has joined #dri-devel
<jekstrand>
karolherbst: What do you mean? I think I've implemented it all. :)
<karolherbst>
I think rusticl should provide a kernel fallback for in VRAM buffers/textures and a CPU copy fallback for CPU ones, but drivers might do better in some cases
<karolherbst>
jekstrand: if a driver would do that in shaders anyway, there is no point in implementing clear_buffer if we can have the helper in a central place
<jekstrand>
karolherbst: Sure
<alyssa>
karolherbst: doesn't have to be rusticl
<karolherbst>
yeah.. can be some gallium helper
<alyssa>
stick a u_clear_buffer_compute and u_clear_buffer_sw in gallium/auxiliary, default callbacks
<karolherbst>
it's a bit fun that CL doens't know blitting
<alyssa>
same thing we do for subdata
rcf has joined #dri-devel
alyssa has quit [Quit: leaving]
<karolherbst>
alyssa: ahh sure, then drivers can call the fallbacks
<karolherbst>
fine by me
<karolherbst>
I think I will implement partial updates for shadow buffers, but uhhh... :( that's annoying because that means I have to start range tracking
<karolherbst>
ahh there is images_kernel_image_methods :)
<karolherbst>
nir_intrinsic_image_deref_format and nir_intrinsic_image_deref_order stuff
mbrost has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
<karolherbst>
maybe I miss some more patches?
<karolherbst>
same for the fill_buffer tests
<karolherbst>
*buffer_fill
<jekstrand>
karolherbst: Passes here. Not sure what's different.
<karolherbst>
on gen12?
<jekstrand>
yup
<karolherbst>
okay
<karolherbst>
ohh maybe it was that other patch
<karolherbst>
for nir_lower_int64.c
<karolherbst>
ehh
<karolherbst>
maybe it's some local issue here, let me see
rcf has quit [Quit: WeeChat 3.2.1]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
zigotonus has joined #dri-devel
eukara has quit [Read error: No route to host]
eukara has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
zigotonus has quit [Remote host closed the connection]
<karolherbst>
jekstrand: on your branch I get "test_thread_dimensions: ../src/gallium/drivers/iris/iris_batch.c:444: iris_use_pinned_bo: Assertion `iris_get_backing_bo(bo)->real.kflags & EXEC_OBJECT_PINNED' failed." :(
shankaru has quit [Quit: Leaving.]
Haaninjo has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
<h0tc0d3>
Stupid politics has now come to opensource. I wanted to participate in the GSOC, but I was denied because I am from Russia. Although my level of knowledge is quite high, and I would like to help open source and get additional knowledge. Also, the funny thing is that Mathorks equated me with terrorists because I'm from the Russian Federation and removed my honestly bought matlab license. In their opinion, scientists from the
<h0tc0d3>
Russian Federation use matlab to design rockets, weapons, and kill people... Shit...
<h0tc0d3>
Words about tolerance are just empty talk.
rcf has joined #dri-devel
i-garrison has quit []
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
i-garrison has joined #dri-devel
rcf has quit [Quit: WeeChat 3.2.1]
rcf has joined #dri-devel
rcf has quit []
rcf has joined #dri-devel
ppascher has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
* jekstrand
kicks off a clover run
<orbea>
h0tc0d3: i dont have any say in this, but yea its disturbing.
tzimmermann has quit [Quit: Leaving]
<alanc>
no one here has any say in it - GSOC is run by google, who as a US company, has to comply with US law or face the penalties
<karolherbst>
yep
Haaninjo has joined #dri-devel
mbrost_ has joined #dri-devel
<Company>
I very much think Open Source does way too little against Russia
Emmy_ has joined #dri-devel
<karolherbst>
can we cut this short though? :D
<Company>
if you don't do anything, you're complicit
mbrost has quit [Read error: Connection reset by peer]
<karolherbst>
don't do wars and if your government starts one, do something against your government. period.
<karolherbst>
we really don't have to say more than that, no?
<Company>
we do have to say more than that
Major_Biscuit has joined #dri-devel
<karolherbst>
yeah.. with beer in a pub :D but I wouldn't discuss it on a public IRC channel
<h0tc0d3>
But this is nonsense. They should impose sanctions against Putin or the oligarchs. I am an ordinary citizen, and I want to contribute to the development of open source.
<Company>
I know
<Company>
but you live in the country and pay taxes to those people
<karolherbst>
I live in Germany and we still find multiple boombs a week
<orbea>
and US people pay taxes to people who destroyed great many countries
<karolherbst>
do you think it's fair if you have to leave your house, because of some WW2 bomb?
<karolherbst>
in 2022?
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
orbea: yep, true
<orbea>
there is plenty of blame to go around, fighting each other doesn't make any of it better
<karolherbst>
fight your government instead
<Company>
well, it's kinda our fault that we didn't remove the bombs in the last 80 years
<karolherbst>
:P
<karolherbst>
Company: well :P
<karolherbst>
you couldn't anyway
<karolherbst>
we have specialist for that, you don't
<karolherbst>
:D
<Company>
but the Nazis couldn't have fought the war if my grandparents hadn't helped them
<karolherbst>
yeah... people have _some_ responsibility for their governments action
<Company>
mt grandfather was a very neutral person, who juist built trainn tracks in Poland and the Baltics
<h0tc0d3>
In the same way, Google and other companies profit from the work of our developers. Their contribution to open source is not small. Why does everyone want to mix all with politics and instead of creating good things they do crap?
<karolherbst>
because your nation started a war
<karolherbst>
it's as simple as that
<jekstrand>
Let's avoid blamy language, please.
<airlied>
there is nothing currently stopping you from contribution to open source, GSoC is not the only avenue
<karolherbst>
jekstrand: yeah.. sorry
<airlied>
getting paid for contributions might be a problem, but I don't think that is just Google's problem
<jekstrand>
Yes, the current situation is crap. It's not the fault of anyone in this channel. Just because a person lives in a country doesn't mean their responsible for the actions of its leaders.
<karolherbst>
I am kind of on the edge about this topic anyway...
<karolherbst>
I guess a lot of people in middle/estern europe are
<Company>
I've revisted the original discussions about the GPL phrasing in recent weeks
<Company>
because they had a long discussion about it in the 80s
<h0tc0d3>
I can participate in GSOC by giving up money, I don't need it. It is more important for me to know and contribute to the future of other people.
<h0tc0d3>
But because of politics, they don't even let me do that.
<airlied>
h0tc0d3: you can just contribute to most open source projects, you don't need the gsoc framework to do it
<jekstrand>
Similarily, Google has to work within the restrictions they have. With the current banking situation, the mechanics of paying people in Russia from outside is difficult, even if they didn't have other international pressure objectives.
<jekstrand>
h0tc0d3: You don't need to be part of GSOC to contribute.
<alanc>
given the number of countries currently imposing sanctions, there's a very limited number of countries left with high tech companies to fund stipends from - perhaps China & Isreal?
<jekstrand>
There's nothing that says an open-source project can't take your patches.
<Company>
...
<h0tc0d3>
I know. But the main point of GSOC is that I choose a project that interests me, and they will help me get the necessary knowledge and structure knowledge. Some projects are quite complex and large.
<jekstrand>
h0tc0d3: GSOC does provide some structure, yes, but really it just pairs you up with a mentor person and sets a couple deadlines. It's the project mentor, not Google, that helps you get up to speed. Lots of people have gotten involved in open-source without GSOC.
<jekstrand>
karolherbst: clover is looking a lot less healthy than rusticl. :)
<karolherbst>
:)
<karolherbst>
I am not surprised
<h0tc0d3>
I have open source experience and submit patches, but I would like to grow taller.
<Company>
you could just pick a project from the GSOC suggestions that wasn't selected and decide to work on iot
<Company>
I'm sure the mentors for those tasks would be happy to help you anyway
<jekstrand>
Yup
<karolherbst>
yeah, definitely. I wouldn't see a problem in that either
<h0tc0d3>
I would like to take this project, but without a mentor it will be difficult. The DRM code is quite large and complex. Although I read a lot of documentation, and submitted several patches to the kernel, and several were accepted. There is much that I don't understand. https://www.x.org/wiki/AMDGPU2022/
<bnieuwenhuizen>
note that the task has potential mentors listed, it might be good to get in touch with them anyway, they might be willing to help outside of gsoc
<Company>
yeah, I was about to suggest poking siqueira here or senging him an email explaining the situation and asking about it
<h0tc0d3>
Company, I already do it. So far there is no answer.
Major_Biscuit has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
<jekstrand>
karolherbst: So this is fun.... rusticl just hangs on ARM. No idea why.
<karolherbst>
yeah.. I plan to rework the func pointer checking part anyway
<jekstrand>
idk if panfrost even has the ioctl
<jekstrand>
I kinda doubt it
<karolherbst>
it's not required now anyway
<karolherbst>
let me write a small hacky patch
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst>
jekstrand: pushed to rusticl/wip_next
<karolherbst>
you need the shadow stuff anyway if you don't have that function :)
<jekstrand>
karolherbst: Would you mind quick rebasing on origin/main to pick up the latest iris patches? Then I'll rebase on that.
<karolherbst>
I already should have everything
<karolherbst>
I hope
<karolherbst>
I sorted the history so you should see what's missing or not
<karolherbst>
but I have the blorp/clear_buffer stuff and iris_bo_alloc fixes
<jekstrand>
Ok, rebased.
ngcortes has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
ngcortes has quit []
<karolherbst>
what I hate the most about debugging rust code is the inability for gdb to look behind Derefs :D
<karolherbst>
so i.image_desc becomes i.ptr.pointer.image_desc
<karolherbst>
ehh
<jekstrand>
Woo! It's crashing inside panfrost
<karolherbst>
nice
<karolherbst>
where though?
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
<jekstrand>
Ugh... no one does glsl_type_singleton_init_or_ref()
<karolherbst>
oops
<karolherbst>
sorry for ignoring that part
<karolherbst>
I guess we should call it when constructing the platform or so
<jekstrand>
Yeah
<karolherbst>
although there are functions in CL to unload the compiler stack
<karolherbst>
(and get it implicitly loading once you changed your mind and compile stuff again)
<karolherbst>
yeah soo.. no good idea where to put it :)
<karolherbst>
there is std::sync::Once though
<jekstrand>
I'm adding one to panfrost_create/destroy_screen
<karolherbst>
who is responsible for calling glsl_type_singleton_init_or_ref though?
<karolherbst>
I guess rusticl should call it somewhere?
<jekstrand>
Yeah
<jekstrand>
Basically everyone should
<jekstrand>
I really hate that it exists.
<karolherbst>
well
tales__ has joined #dri-devel
<jekstrand>
But basically everyone who ever touches the GLSL compiler or NIR should take a reference
<karolherbst>
in a perfect world rusticl would be able to ditch the entire loaded compiler stack, but like in hell we would support that
<jekstrand>
Which means both rusticl and panfrost
<icecream95>
jekstrand: I already got rusticl working on Panfrost yesterday, it seems that you hit all the same problems that I did
<jekstrand>
icecream95: Got it in a branch?
<karolherbst>
icecream95: I finished shadow buffers for USE_HOST_PTR today :)
<karolherbst>
so a lot of stuff should actually work as well now
<icecream95>
jekstrand: rusticl-wip, where I started trying to implement function call support in the later commits
pcercuei has quit [Quit: dodo]
<karolherbst>
icecream95: you are very brave
<karolherbst>
ehhh you are not allowed to specify a slice_pitch for non 3d or array images, but a row pitch you are allowed to specify for 1d images :)
danvet has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: btw, I have a custom function inlining code which is like a lot faster than the one we currently have
iive has quit []
<karolherbst>
some thoughts on that might be helpful as I am not sure if it's a good idea or if we need a bigger rework to do like inlining based on thresholds
<jekstrand>
karolherbst: Oh? How's it faster?
<karolherbst>
it only inlines into the entry point end leaves other functions alone
<jekstrand>
And then you iterate until the entrypoint has no calls?
<karolherbst>
so you don't end up with hundreds copies of everything
<karolherbst>
jekstrand: yeah, basically
<karolherbst>
that's the part I don't like
<karolherbst>
but
<jekstrand>
Yeah, I could see that being faster, potentially.
<karolherbst>
it still didn't allow me to compile more luxmark kernels, but it got further :)
<jekstrand>
heh
<karolherbst>
speed isn't the issue though
<karolherbst>
memory is
<karolherbst>
one kernel ended up with like ssa_2000000 and stuff
<karolherbst>
then I gave up because nir_print_shader just took minutes
<karolherbst>
anyway, before we figure out function calling it's the best we can do to make it more likely to compile huge kernels
<karolherbst>
jekstrand: I think I got to intel RA stuff and then it just looped forever
ngcortes has joined #dri-devel
<karolherbst>
guess if you spill thousend/millions values the compiler can't handle it