mehdi-djait3397165695212282475 has joined #dri-devel
mrbro has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
u-amarsh04 has quit []
amarsh04 has joined #dri-devel
fab has joined #dri-devel
eukara has joined #dri-devel
mrbro_ has joined #dri-devel
mrbro has quit [Ping timeout: 480 seconds]
bolson has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
The_Company has quit []
benjaminl has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
jkrzyszt has joined #dri-devel
vliaskov has joined #dri-devel
gnuiyl has quit []
dolphin has joined #dri-devel
lynxeye has joined #dri-devel
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
rasterman has quit []
<sima>
just rolled drm-fixes to -rc1
<sima>
mripard, airlied ^^
rasterman has joined #dri-devel
<mripard>
sima: awesome, thanks
<airlied>
sima: did I not push that out? oops
* airlied
had a disk fail in the raid1 I do builds on, just just got some new disks and been rsyncing
<chaos_princess>
is this the correct chat channel for gpu native context, and virtio stuff? if so - i am working on a vmm which supports different host and guest page sizes, and need the guest to align it's gpu allocations to host page size. i thought of just aligning to the maximum supported page size on the architecture, but ran into concerns that it could bloat memory usage in case of many small
<chaos_princess>
bos. the suggestion was to expose host page size via "extended virtio protocol". i wasn't able to figure out what specifically that is, and while i can introduce a vmm-specific side channel, that sounds wrong. how exactly that info should be communicated, and does it mean that i would need to talk to whoever maintains the virtio protocol to standardize all that?
<mripard>
airlied: sure, let's blame RAID :)
<airlied>
the disk has been gone for weeks, I just blame the new disks arriving distracting me from doing whatever I was doing :-P
apinheiro has joined #dri-devel
WhyNotHugo has left #dri-devel [#dri-devel]
<karolherbst>
mhh.. maybe I hate the "I'd need 100 different variants for my copy kernels" aspect of my plan enough to go straight to resource_copy_region and just pipe_cap it....
rasterman has quit [Quit: Gettin' stinky!]
surajkandpal1 has joined #dri-devel
phasta has joined #dri-devel
surajkandpal has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
Kayden has quit [Ping timeout: 480 seconds]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
Kayden has joined #dri-devel
fab has quit [Quit: fab]
rasterman has quit [Quit: Gettin' stinky!]
guludo has joined #dri-devel
fab has joined #dri-devel
pcercuei has joined #dri-devel
feaneron has joined #dri-devel
rgallaispou1 has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
guludo has quit [Quit: WeeChat 4.5.1]
agd5f has quit [Ping timeout: 480 seconds]
<lumag>
mlankhorst, mripard, tzimmermann: could you possibly merge back drm-misc-fixes into drm-misc-next (or just pick up current -rc1 into it)? It would be nice to get all the fixes for drm/display/* into the drm-misc-next branch
ADS_Sr__ has joined #dri-devel
macromorgan_ has joined #dri-devel
edolnx has joined #dri-devel
edolnx_ has quit [Ping timeout: 480 seconds]
ADS_Sr_ has quit [Ping timeout: 480 seconds]
macromorgan has quit [Ping timeout: 480 seconds]
<mripard>
lumag: done
<lumag>
mripard, thanks!
<mlankhorst>
ah just got beat to it :)
amarsh04 has quit []
amarsh04 has joined #dri-devel
surajkandpal1 has quit [Ping timeout: 480 seconds]
<tzimmermann>
mripard, thanks for taking care of it
hansg has joined #dri-devel
<tzimmermann>
mripard, mlankhorst, i'll take over drm-misc-next this cycle. there are still 2 patches left in drm-misc-next-fixes. i'll send them today, and drm-misc-next withing the next days. ok?
<mripard>
tzimmermann: I sent them as part of the drm-misc-fixes PR today
<tzimmermann>
mripard, great. thanks a lot!
ADS_Sr__ has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
ADS_Sr has joined #dri-devel
<mlankhorst>
tzimmermann: can't remember if it's me this cycle
<mlankhorst>
but I think I have a break until next -next
<tzimmermann>
mlankhorst, it's my turn with drm-misc-next
<mlankhorst>
ah go right ahead, it's all yours. I think we need to disable pushing to next-fixes again
<mlankhorst>
seems to be already protected :)
<tzimmermann>
looks like it
<mripard>
yeah, I did it this morning as well :)
<tzimmermann>
thanks mripard
mvlad has joined #dri-devel
agd5f has joined #dri-devel
surajkandpal has joined #dri-devel
edolnx_ has joined #dri-devel
edolnx has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
ADS_Sr has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
ADS_Sr has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
kaiwenjon_ has joined #dri-devel
kaiwenjon has quit [Read error: Connection reset by peer]
coldfeet has quit [Quit: leaving]
coldfeet has joined #dri-devel
fab has quit [Remote host closed the connection]
heat has joined #dri-devel
fab has joined #dri-devel
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
rcf has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
<bbrezillon>
sima: don't know if you're the right person to ask, but I'm trying to make sense of drm_syncobj_array_wait_timeout(). One thing in particular struck me: we're setting the task in an interruptible state, waiting for a dma_fence callback to wake us, but we're only registering our fence callback after going to sleep
<sima>
bbrezillon, that's standard open-coded linux wait loop
rgallaispou has quit [Read error: Connection reset by peer]
bolson has joined #dri-devel
<sima>
first you need to set your task state to sleeping, then you must re-check the wait condition, then you call schedule()
<sima>
if you do this in a different order, you might miss a wakeup and be stuck forever, which isn't great
<heat>
note that you only go to sleep in schedule() (or schedule_timeout()), despite your state being INTERRUPTIBLE
<sima>
the wake-up has the inverse order: 1. set the wait condition 2. call wake_up, which should set your task back to TASK_RUNNING to make sure that if the wakeup happened right between steps 2 and 3 (3 is calling schedule()) you don't miss the wakeup
dolphin has quit [Quit: Leaving]
<sima>
yeah schedule() is just a call to the schedule to figure out whether anything changed, it's not a "suspend me now" call
<heat>
a few years back i was really confused on how set_current_state never had a problem where a timer irq would arrive between set_current_state and schedule, and that's because there are simply safeguards for it, you can't get preempted in the middle of those
rgallaispou has joined #dri-devel
kzd has joined #dri-devel
<sima>
yeah this predates preemption
<bbrezillon>
except that's not what I'm seeing here
<bbrezillon>
my thread enters sleep before registering the fence cb
<bbrezillon>
that is, when set_current_state(TASK_INTERRUPTIBLE) is called
<heat>
set_current_state(TASK_INTERRUPTIBLE) does not enter sleep
<bbrezillon>
okay, I need to check my tracing then
<heat>
set_current_state(TASK_INTERRUPTIBLE) expands to, roughly, smp_store_mb(current->__state, TASK_INTERRUPTIBLE);
<sima>
I think I've stumbled over a hilarious race on the wake-up side and there's a very special function for that, but I think that doesn't apply here
<sima>
bbrezillon, ok I think there might be a bug here
<sima>
you need to install the callback/put yourself onto the waitqueue before calling set_current_state
epoch101_ has quit []
<sima>
otherwise again races
<bbrezillon>
yeah, that looks like what I'm seein
epoch101 has joined #dri-devel
<sima>
yeah so that order looks wrong
<sima>
it must be dma_fence_add_callback(); /* sufficient memory barrier, set_current_state() is easiest */; dma_fence_is_signaled();
<sima>
except we want a fast path that just checks first once (due to lazy signalling semantics of fences) before we do the expensive dance of adding callbacks
<bbrezillon>
I guess we're better off using wait_event_interruptible_timeout() with a waitqueue we attach to fence slots then
<sima>
bbrezillon, same issue, just one indirection more
<sima>
that's not going to help I think
<sima>
and we still have the issue of having to listen to multiple wait queues
<bbrezillon>
hm, not sure I follow
<bbrezillon>
if the waitqueue is on the stack, you just wait on this one?
jsa1 has quit [Ping timeout: 480 seconds]
<bbrezillon>
but if you want to do a dummy run to avoid registering the callbacks upfront
<sima>
yeah so there's only one, but you still have to deal with the complexity of multiple fences and having to check them and add callbacks as needed
<bbrezillon>
I think the "are there any remaining unsignaled fences" check should be moved to a sub-function
epoch101_ has quit [Read error: Connection reset by peer]
YuGiOhJCJ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
misyl has quit [Quit: Gone froggin!]
quantum5- has quit [Remote host closed the connection]
quantum5 has joined #dri-devel
FLHerne has quit [Quit: There's a real world out here!]
Daanct12 has joined #dri-devel
FLHerne has joined #dri-devel
tanty has quit [Quit: Ciao!]
tomaw has quit [Quit: Quitting]
tomaw has joined #dri-devel
bbhtt has quit [Quit: Bye!]
bnieuwenhuizen has quit [Remote host closed the connection]
Plagman has quit [Remote host closed the connection]
bbhtt has joined #dri-devel
Danct12 has quit [Read error: Connection reset by peer]
Plagman has joined #dri-devel
bnieuwenhuizen has joined #dri-devel
tanty has joined #dri-devel
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
mvlad has quit [Remote host closed the connection]
misyl has joined #dri-devel
mrbro_ has quit [Ping timeout: 480 seconds]
epoch101 has quit []
mivanchev has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
coldfeet has quit [Quit: Lost terminal]
haaninjo has joined #dri-devel
yshui_ has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
kaiwenjon has joined #dri-devel
guludo has quit [Quit: WeeChat 4.5.1]
<tnt>
I'm a bit lost with GL and linking and stuff. So for a bit of context, I'm working with the intel-compute-runtime OpenCL runtime and trying to maintain the CL/GL sharing interop extension. And in general it's been working fine.
<tnt>
However I've encountered a weird issue where I can't get the symbols I need.
<tnt>
So the CL runtime itself doesn't link directly to any GL library. It tries to find the symbol it needs at runtime and assumes the client app will have loaded GL and created context as needed before it tries to create a CL context.
<tnt>
And then I just use dlsym() to find the few symbols I need. And in general, it's been working fine.
<tnt>
But now I have an app for which dlsym() of gl symbols ( like glGetString or such ) works fine. But I get NULL for both glXGetProcAddress and eglGetProcAddress ...
sima has quit [Ping timeout: 480 seconds]
<HdkR>
tnt: Sounds like it isn't linking to libGL but instead libOpenGL, which means it doesn't get GLX symbols, and also not linking against libEGL. So effectively surfaceless
<tnt>
HdkR: Before that call to CL init, I used glfw to create an actual window on-screen so I definitely have a surface.
jsa1 has quit [Ping timeout: 480 seconds]
<soreau>
libepoxy?
<karolherbst>
tnt huh.... I mean rusticl also just uses dlsym
<karolherbst>
though.. mhh
<karolherbst>
if the gl lib is bound locally, that might cause issues
<karolherbst>
but then all bets are kinda off to be fair
anarsoul|2 has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
<tnt>
karolherbst: yes, I basically modelled that behavior after what rusticl does.
<karolherbst>
sounds like a problem I'll have to deal with as well...
<tnt>
Nope, rusticl works fine for that application.
<karolherbst>
hah
<karolherbst>
then do whatever rusticl does :D
<karolherbst>
though let me see if we do something special for glXGetProcAddress ...
<karolherbst>
nope...
<tnt>
Do you even use it at all ?
anarsoul has quit [Ping timeout: 480 seconds]
<tnt>
So the issue is definitely GLX seem to be loaded as local because if I somehow force loading it as RTLD_GLOBAL at the beginning of the non working app, it starts working. I'm not sure why it works for rusticl though.
<karolherbst>
what do you mean use it at all?
<karolherbst>
glXGetProcAddress? yeah, it's used
anarsoul|2 has quit [Ping timeout: 480 seconds]
<tnt>
karolherbst: Yeah sorry, I had some memory of long ago where I think you were accesing the interop function directly without going through glXGetProcAddress.
<karolherbst>
yeah.... it might also be, that rusticl ends up with a local copy of that stuff.. I haven't actually checked if that could happen or not, but I kinda doubt it, because it's not linking against those bits at all