ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
anarsoul has quit [Quit: ZNC 1.8.2 -]
tzimmermann_ has quit [Ping timeout: 480 seconds]
anarsoul has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
Thymo has joined #dri-devel
Thymo_ has quit [Ping timeout: 480 seconds]
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 for a riddle to chew on, and there's a general help wanted doc at
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
<karolherbst> it's not
<karolherbst> jenatali: maybe this crate abuses it, but:
<karolherbst> sounds like a mutation to me
<karolherbst> &mut is more about exclusive ownership than anything else in the end
<karolherbst> you can only have one &mut to an object, but several &s
<jenatali> Well yeah, that's because to borrow checker enforces that only one view can mutate an object
<airlied> robclark: looks like a bug in glsl linker when fp16 consts are lowered
<karolherbst> I bet that impl does use unsafe {} blocks under the hood though
<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
<jenatali> Weird
<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
<karolherbst> specifically checked_call
<HdkR> Sounds similar to a concept or consteval =o
<karolherbst> whatever you please :D
<karolherbst> although I could have implemented as a weirdo Deref trait...
<karolherbst> maybe
<karolherbst> but...
<karolherbst> it's real nice
<pinchartl> -ENOPARSE
<karolherbst> $(...) defines a block which might be there or repeat or whatever
<karolherbst> and you can transform that to something
<karolherbst> but yeah...
<karolherbst> it's hard at first to understand the macro syntax
<karolherbst> but in the end you write a transformer based on the AST
<karolherbst> and you can match on your input
<karolherbst> and even parse to different things depending on what case matches
<karolherbst> so I used that to parse to something else if the expression ends with "?"
<pinchartl> are you trying to compete with perl for the most cryptic code ?
<karolherbst> kind of
<karolherbst> but that's just the macro definition
<karolherbst> as if cpp macros or C++ templates are in any way easier to understand :p
<karolherbst> as long as they are simple to use, nobody gives a damn
<pinchartl> cpp macros are simple, but they're not very powerful as a result
<karolherbst> yeah
<karolherbst> they don't allow a random syntax
<karolherbst> neither do C++ templates
<pinchartl> C++ templates are more interesting. they can't fully replace cpp macros though
<karolherbst> they are even weaker tbh
<pinchartl> "random syntax" doesn't fit in the same sentence as "code readability" unfortunately
<karolherbst> it's super painful to write templates
<HdkR> Good job Rost for doing cool stuff :D
<HdkR> Rust even
<karolherbst> pinchartl: you define the syntax you deem good for your use case
<robclark> karolherbst: so rust learned from lisp hygienic macros?
<karolherbst> you want to "enhance" a struct? then your input syntax is just a struct
<pinchartl> karolherbst: yes, that's what I said, it's a write-only system :-)
<karolherbst> and you surround it by a macro call
<pinchartl> all nice for the developer, a nightmare for reviewers
<karolherbst> meh
<karolherbst> it's not that bad
<pinchartl> that's because you're on the writing side of the code :-)
<karolherbst> :D
<karolherbst> but honestly, once you get your head around it, it's easy
<pinchartl> it's never that bad when you've written code. to realize how bad it is, you need to be on the reading side
<pinchartl> I can say the exact same thing about templates :-)
<karolherbst> I've read other peoples macros
<pinchartl> once you get your heard around it, it's easy
<karolherbst> ehhh
<clever> one sec
<pinchartl> the real question is how difficult it is to get your head around it
<karolherbst> I am sure clever now searches for a 100 loc template :D
<karolherbst> pinchartl: not very, as you don't think of it as a macro in the end
<karolherbst> you just write code
<karolherbst> but replace certain things with macro patterns where you want things to be inserted
<clever> pinchartl: how would you rate this code, in terms of readability?
<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
<clever> this chunk of code should have the identical effect as that asm variant
<pinchartl> karolherbst: does rust have templates btw ?
<karolherbst> they have generics, but no templates in that sense
<pinchartl> ok
<karolherbst> you don't need templates anyway
<karolherbst> one of the features I never missed
<pinchartl> I miss templates in C :-)
<karolherbst> yeah...
<karolherbst> in C yes
<karolherbst> :D
<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
<karolherbst> rust added () for that