Thymo has quit [Remote host closed the connection]
Thymo has joined #dri-devel
pendingchaos_ has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
pnowack_ has joined #dri-devel
pnowack has quit [Ping timeout: 480 seconds]
Hi-Angel has quit [Ping timeout: 480 seconds]
adavy has quit [Read error: No route to host]
<holmanb>
I hope my question is appropriate for this channel, sorry in advance if not. Anybody have tips for getting started w/Mesa & gpu development? Have a little kernel experience, and have done some basic w/user apis (opengl&vulkan hello world, basically). More comfortable w/C than C++. Ready to dive into a project, but would appreciate some direction/suggestion.
<kisak>
in general, a bunch of the regular contributors are either asleep or out enjoying their weekend right now. Here's as good as anywhere to ask around. Personally, I can't really give guidance, but it might make sense to look around the bugtracker https://gitlab.freedesktop.org/mesa/mesa/-/issues for a riddle to chew on, and there's a general help wanted doc at https://docs.mesa3d.org/helpwanted.html
The_Company has quit []
<holmanb>
Thanks for the pointers, kisak. My timing is poor, I understand. I've been lurking for a while now; if people respond at a later date I will see it.
gpoo has quit [Ping timeout: 480 seconds]
bbrezillon has quit [Read error: Connection reset by peer]
mripard has quit [Read error: Connection reset by peer]
mripard has joined #dri-devel
bbrezillon has joined #dri-devel
pnowack_ has quit []
lemonzest has joined #dri-devel
Duke`` has joined #dri-devel
mlankhorst has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Daanct12 has joined #dri-devel
gouchi has joined #dri-devel
rasterman has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
Company has joined #dri-devel
Hi-Angel has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
tobiasjakobi has joined #dri-devel
imre has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
tzimmermann__ has quit []
Daaanct12 has quit [Remote host closed the connection]
Daaanct12 has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gpoo has joined #dri-devel
gouchi has joined #dri-devel
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
Anelia25F has joined #dri-devel
Anelia25F has quit []
<imirkin_>
kisak: is there any other way to enjoy the weekend than to be sound asleep? :)
<imirkin_>
holmanb: i think many people get started by solving issues that they have themselves
<imirkin_>
and asking questions about how to figure out what's wrong / debug / etc
<HdkR>
Wait, most people don't work 60 hours a week?
<HdkR>
I'm shook
<imirkin_>
HdkR: they do. hence the need to sleep on the weekends
<HdkR>
The weekend is perfect for squeezing more hours in though :P
<imirkin_>
man, i remember college ... i could sleep 4hr/night and be totally fine the next day
<imirkin_>
that is no longer the case =/
The_Company is now known as Company
<alyssa>
imirkin_: I can't do that, am I doing uni wrong?
<imirkin_>
alyssa: in fairness, i lost that ability by senior year
<kisak>
imirkin_: fair point, I could have written sleep and/or enjoying their weekend
<holmanb>
imirkin_: sounds like I need to start finding issues
<imirkin_>
holmanb: what hardware do you have easy access to?
<holmanb>
imirkin_: 1070ti in my primary machine, radeon r7 m260X / HD Graphics 5500 in a couple of old laptops, whatever a 2013 era macbook has, and a pile of aging dev boards (rpi2/3, freedom board, xylinx fpga, sifive)
<imirkin_>
holmanb: if you don't have any problems yourself, you could look through the bug tracker for issues that you can reproduce / find interesting to potentially fix, and discuss with the relevant dev team for potential approaches
<holmanb>
If I asked really nicely I could maybe swap my 1070ti for a vega 56 too
<holmanb>
imirkin_: good call, I can do that
<imirkin_>
there's an unfortunate reality though that the easy bugs get fixed fast, and the hard bugs get fixed slow/never
<imirkin_>
so there's a big bias towards "hard" stuff in the tracker
<holmanb>
That makes sense
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<Venemo>
holmanb: Mesa is a vast project. My suggestion is this: find an area that interests and motivates you. This could be eg. getting your favourite game working properly, fixing an issue that annoys you or help get a new driver for your old GPU working. Then talk to the people who're responsible for that area and start hacking away.
<Venemo>
Sounds like the R7 M260X is on the lowest end of what RadeonSI and RADV support, and the Intel 5500 may be a good fit for testing Crocus. I'm not familiar enough with the others you listed.
<holmanb>
Venemo: I hadn't heard of Crocus before, glad Intel pushed for gallium for existing/older hardware.
<holmanb>
Venemo: Thanks for the suggestions!
<emersion>
crocus isn't an intel initiative iirc
<holmanb>
Oh I assumed it was, oops
<Venemo>
AFAIK Crocus is the pet project of some people on this channel to get another nail in i965's coffin
<karolherbst>
hopefully they succeed
<karolherbst>
jenatali: why is clCreateUserEvent so annoying? :(
<Venemo>
holmanb: unfortunately the 1070 is of limited usefulness, unless you are interested in hacking nouveau. sadly it's still missing reclocking
<Venemo>
that's no fault of the nouveau devs, tho
<jenatali>
karolherbst: Good question :P
<karolherbst>
holmanb: if you are interested in compiler bits you could work on the nir path for nouveau, but that requires some knowledge already... so in the end I always recommend newcommers to work on annoying issues, they are frustrated about, because after fixing those they might be less frustrated by their machine :D
<Venemo>
also it's easier to stay motivated if you work on something that affects you / you care about in the first place
<Venemo>
I think this is the hardest part of contributing to any FOSS project.
<Venemo>
there are many issues that annoy me or features I'd like to see in various projects but not enough to keep me motivated through learning the project
<Venemo>
what broke the ice, so to speak, for me was to set a goal, and just keep on hacking, reading the code, and asking annoying questions here, till I got it right
<holmanb>
@karolherbst I wouldn't mind doing compler bits eventually, however I agree that's probably not my best starting place. I've done some asm for a few different instruction sets, but my understanding of the inner workings of compilers is very high level theoretical stuff I've picked up from watching conference talks - and even that was mostly llvm/cpu stuff.
<holmanb>
venemo: yeah nouvou super interesting at the moment, and <insert grumble about silicon prices>, so I'm content learning on my older hardware for now.
<Venemo>
I guess you can try to trade the 1070 for a comparable AMD device if you want, but as said your M260X can probably run RadeonSI and RADV already.
<holmanb>
I'm planning on testing out RadeonSI and RADV when I get a chance (unfortunately can't spend any real time on that until next week)
adavy has joined #dri-devel
iive has joined #dri-devel
bcarvalho__ has quit []
rsalvaterra_ has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
rsalvaterra_ has quit []
rsalvaterra has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<karolherbst>
airlied: seems like robclark fixed cl images for llvmpipe :D
tzimmermann has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
APic has quit [Read error: Connection reset by peer]
APic has joined #dri-devel
adjtm has quit [Ping timeout: 480 seconds]
<robclark>
karolherbst: looks like async_copy_global_to_local and friends is failing because `b->shader->info.shared_size` is zero.. which seems fairly incorrect.. does that ring a bell? Does nouveau ignore the shared_size?
<airlied>
robclark: there are 2 shared sizes
<airlied>
one in shader one in state
lemonzest has quit [Quit: WeeChat 3.2]
<airlied>
add them together
<robclark>
oh, `cso->req_local_mem` Iguess
<airlied>
yeah that one
<robclark>
cool, thx
<robclark>
actually looks like we should only use `cso->req_local_mem`.. mesa/st initializes that to `shader->info.shared_size`..
<airlied>
cant remember what llvmpipe does
adjtm has joined #dri-devel
<robclark>
looks like it adds the two.. although I suppose asking for too much shared mem perhaps doesn't hurt on cpu?
<robclark>
looks like radeonsi just uses cso->req_local_mem
<airlied>
robclark: hmmm looking at history I think lavapipe might be inconsistent with st, I should likely fix that
<imirkin_>
does someone remember offhand how the install prefix thing works with ninja? like let's say i want to say prefix=/bla but secretly install to /foo/bla, there's something i can say when installing?
<imirkin_>
aha, looks like DESTDIR=/foo ninja install would do the trick for me
Duke`` has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<airlied>
robclark: you got any memories of fp16 + spec/glsl-es-1.00/linker/glsl-mismatched-uniform-precision-unused failing
<airlied>
not sure why this failure would be driver specific
<airlied>
Kayden: oh looks like you fixed it ages ago, not sure why llvmpipe fails it
<airlied>
oh I wonder if it goes away with some fp16 lowering I'm not doing
<robclark>
airlied: doesn't ring a bell.. but for $reasons (iirc, related to vs <-> tess/gs linkage?) we don't lower fp16 in vs
Ristovski has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
macromorgan is now known as Guest6424
Guest6424 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
Ristovski has joined #dri-devel
macromorgan is now known as Guest6425
Guest6425 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<karolherbst>
dcbaker: mhh I actually need cargo support now. Do you have anything that works on top of current meson?
<karolherbst>
jenatali: ohh seems like CL is less thread safe than I thought it is
<jenatali>
karolherbst: oh?
<karolherbst>
jenatali: soo.. shared objects need to be locked by the application and only function internal state have to be thread safe
<karolherbst>
so if you use lockfree structures for evertyhing, you are safe
<jenatali>
Not sure what you mean. What locking methods?
<karolherbst>
e.g. an application calling clSetMemObjectDestructorCallback _and_ clReleaseMemObject can crash if the application doesn't lock and that's still a valid CL implementation
<karolherbst>
just calling clSetMemObjectDestructorCallback from multiple threads shouldn't crash on the same object
<jenatali>
Well, sure, it's invalid to reference an object without an actual reference to the object... i.e. you shouldn't have a pointer to it without doing a retain
<jenatali>
Do you have an example which doesn't involve a release?
<karolherbst>
not a good one. but I think that's valid for any different functions operating on the same object
<jenatali>
I don't think that's right
<karolherbst>
"OpenCL memory objects, program objects and kernel objects are created using a context and can be shared across multiple command-queues created using the same context. Event objects can be created when a command is queued to a command-queue. These event objects can be shared across multiple command-queues created using the same context."
<karolherbst>
ehhh
<karolherbst>
wrong part
<karolherbst>
"The application needs to implement appropriate synchronization across threads on the host processor to ensure that the changes to the state of a shared object (such as a command-queue object, memory object, program or kernel object) happen in the correct order (deemed correct by the application) when multiple command-queues in multiple threads are making changes to the state of a shared object."
<jenatali>
Sure, the app needs to make sure their ordering is correct, if order matters
<karolherbst>
well which means you kind of have to lock regardless
<karolherbst>
I mean.. for which function does the order not matter
<karolherbst>
my point is rather, I won't have to "lock" an internal object if I can do changes in a thread safe manner
<jenatali>
The main thing is: "All OpenCL API calls are thread-safe except those that modify the state of cl_kernel objects"
<jenatali>
Sure, doesn't need to be a lock explicitly, just thread-safe
<karolherbst>
sure, I just use thread safe structures not requiring any locking
<karolherbst>
mhh
<karolherbst>
wondering what happens if I leave intermediate state on an object...
<karolherbst>
ehh
<jenatali>
"An OpenCL API call is considered to be thread-safe if the internal state as managed by OpenCL remains consistent when called simultaneously by multiple host threads. OpenCL API calls that are thread-safe allow an application to call these functions in multiple host threads without having to implement mutual exclusion across these host threads i.e. they are also re-entrant-safe."
<karolherbst>
have intermediate state
<karolherbst>
yeah..
<karolherbst>
I guess if I modify two fields at once I am in trouble
<jenatali>
Yeah, or if you read two fields at once, you need to read them atomically together
<jenatali>
Much simpler to just... lock the whole object
<karolherbst>
annoying
<karolherbst>
although
<karolherbst>
as the application does have to ensure order of operations...
<jenatali>
Yeah, most objects aren't really stateful though, except kernels, which aren't thread-safe
<karolherbst>
yeah
<jenatali>
It's really just... if you enqueue commands onto the same queue from 2 threads, that needs to be okay, they can just be queued in an indefinite order
<karolherbst>
I think it would be fine to not have those locks.. I didn't really hit anything requiring absurd amount of changes yet
<karolherbst>
right
<karolherbst>
and there are lockfree queue implementations as well
<karolherbst>
lockfree in the sense of me implementing that stuff
<karolherbst>
:D
<jenatali>
Feels like overkill for something that doesn't need to be low-overhead, a locked impl is generally just simpler
<karolherbst>
so I finally fully understood what a &mut reference is in rust and that opens up a huge amount of possibilities
<karolherbst>
right.. just rust makes it annoying
<jenatali>
Yeah I'll admit I haven't tried looking into multithreading or thread-safety at all in rust yet
<karolherbst>
jenatali: thing is.. you can only have one shared mutable reference at the same time
<jenatali>
Right
<karolherbst>
or well
<karolherbst>
mutable references can't be shared rather
<jenatali>
In the same scope
<karolherbst>
_but_
<karolherbst>
jenatali: no. generally
<karolherbst>
full application
<jenatali>
Ah, right, it's a panic if you violate that in a way that can't be statically checked
<karolherbst>
even something like Arc<T>, only one as_mut() reference
<karolherbst>
_but_
<karolherbst>
non &mut are allowed to change state
<karolherbst>
as long as it's "safe"
<karolherbst>
soo
<karolherbst>
if you have a totally thread safe Vec impl, "push" can operate on &self
<karolherbst>
instead of &mut self
<jenatali>
Huh, interesting
<karolherbst>
which makes everything just a lot simplier
<jenatali>
Seems wrong though, since &self implies const, not just thread-safe
<karolherbst>
it doesn't imply const
<karolherbst>
why would it?
<jenatali>
I'd expect the lack of mut to mean immutable?
<karolherbst>
nope
<karolherbst>
it doesn't
<karolherbst>
"These ampersands are references, and they allow you to refer to some value without taking ownership of it."
<karolherbst>
and that's it
<jenatali>
Sure... that's the &, but an object without mut is immutable
<alyssa>
karolherbst: "interior mutability" might be the phrase to google?
<alyssa>
jenatali: ^
<karolherbst>
yeah..
<karolherbst>
it's a common thing
<robclark>
airlied: hmm, ok.. we actually un-lower 16b->32b consts in backend since we use a mode for push consts that lets hcN.m automatically convert from cN.m
<karolherbst>
like Arc<RwLock<T>>
<jenatali>
Yeah, interior mutability makes sense when you technically need to mutate something but it doesn't externally appear to mutate, e.g. a cache
<jenatali>
Or a lock
<karolherbst>
or a thread safe Vec
<jenatali>
It's the reason for the C++ mutable keyword, but this is very much an abuse, to mutate a data structure in a way that is externally visible with a const reference
<jenatali>
At least, in my opinion
<karolherbst>
how do you know the iteratore iterates over one more object after you created it without knowing how many objects there were in the first place?
<jenatali>
Iterating doesn't need a mutable reference... push and pop do
<karolherbst>
well.. you can't push if one is iterating over it
<karolherbst>
at least not for Rusts own Vec
<karolherbst>
*with
<jenatali>
Right. One mutable reference is mutually exclusive with any const references
<jenatali>
Of course I don't have any skin in the game here, just seems wrong to me
<karolherbst>
jenatali: ohh all atomics also operate as &self
<karolherbst>
jenatali: yeah, because externally it looks like nothing changes
<karolherbst>
and you never get "broken intermediate" state
<karolherbst>
I was surprised by this as well tbh :D
<karolherbst>
because.. I just assumed changing an atomic value requires &mut
<jenatali>
Yeah I guess that's really what the borrow checker's trying to enforce, anytime you have a non-mutable reference, the data is safe to read, not really about const
<jenatali>
Seems like an abuse of the terminology then, really should be shared vs exclusive instead of mut vs not
<karolherbst>
yeah.. and as long as your &self methods are thread safe...
<karolherbst>
jenatali: well.. if the stdlib is even doing it :D
<jenatali>
Yeah, atomic => modification doesn't require mut, I guess
<karolherbst>
anyway, that's what I meant with "opens up a huge amount of possibilities"
nsneck has quit [Remote host closed the connection]
Hi-Angel has quit [Ping timeout: 480 seconds]
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
iive has quit []
bluebugs has quit [Read error: Connection reset by peer]
bluebugs has joined #dri-devel
pcercuei has quit [Quit: dodo]
<karolherbst>
rust macros are so awesome
gpoo has quit [Ping timeout: 480 seconds]
<pinchartl>
karolherbst: as awesome as C++ templates ? ;-)
<karolherbst>
more
<HdkR>
As awesome as C++ concepts? ;)
<karolherbst>
more
<HdkR>
=o
<karolherbst>
HdkR: you can essentially define your own syntax for random crap
<karolherbst>
and I mean that literally
<karolherbst>
your_macro!( a => {some arg list, ....} <=> {whatever}) or whatever you please
<karolherbst>
and you can generate stuff out of lists you hand in
<pinchartl>
sounds like a macro :-)
<karolherbst>
you could even hide "function" calls
<pinchartl>
same for templates, if you don't have to look at how they're implemented, you just use them :-)
<imirkin_>
it's a factory factory
<karolherbst>
clever: ehh.. that's small
<pinchartl>
clever: "asm". it's not readable :-)
<clever>
pinchartl: vpu-support-pure.h implements functions using plain C, so you can emulate it and understand it
<clever>
vpu-support-native.h uses inline asm to take advantage of the VPU on the rpi, and run fast
<clever>
both files should implement the exact same functionality
<karolherbst>
clever: well.. but that's not very using much of the features of templates
<karolherbst>
I mean those 1000 characters between <> templates
<clever>
and ideally, the templates should let you specify anything the asm can do
<clever>
the asm lets you do 8bit, 16bit, or 32bit math, so i need 8bit, 16bit, and 32bit versions of these functions
tzimmermann_ has joined #dri-devel
<clever>
and i didnt want to write every function 3 * 3 * 3 times (2 operands, and result, can each vary in bit width)
<karolherbst>
clever: I don't see why you'd need that many loc for that :p
<clever>
so templates was the obvious solution
<clever>
karolherbst: the hardest part (where template haskell, and maybe rust??), is that i basically want to run if statements and printf, on compile-time constants, to generate the asm
<pinchartl>
clever: not disputing that. what I meant is that asm() doesn't make code very readable. the template part is not an issue
<pinchartl>
it's a bit annoying that C++ can't store a void in a structure, it makes it more difficult to handle functions returning a value and functions that don't in a generic way