ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
sdutt has joined #dri-devel
nchery is now known as Guest213
nchery has joined #dri-devel
mhenning has joined #dri-devel
<karolherbst>
jekstrand: I found the first program using cl_khr_gl_sharing for real :D
<jekstrand>
oh?
<karolherbst>
some pro video editing tool called davinci resolve
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
<karolherbst>
it doesn't even work with intels compute runtime
<karolherbst>
well.. it fails the same way
<karolherbst>
it is getting stuck
<jekstrand>
karolherbst: Yeah, iris doesn't support the ext
<karolherbst>
well....
<karolherbst>
my hope is, if we do all of that within gallium...
<karolherbst>
didn't look at how much we'd have to support there
<karolherbst>
but best case it's just passing some pointers around, no?
<jekstrand>
Yeah, should be
<karolherbst>
is there an ext on the gl side?
<karolherbst>
gl_khr_cl_sharing I bet would be the name :D
<karolherbst>
ahh.. seems like it's just important GL objects into CL
<karolherbst>
*importing
Guest213 has quit [Ping timeout: 480 seconds]
<jekstrand>
yeah.....
<karolherbst>
the ext doesn't sound toooo terible though
<karolherbst>
internal format mapping and stuff.. sure
<jekstrand>
Yeah, if everything's gallium, it's not too bad
<karolherbst>
"OpenCL memory objects may be created from OpenGL objects if and only if the OpenCL context has been created from an OpenGL share group object or context."
<karolherbst>
I don't think we even care
<jekstrand>
idk what that even means
<karolherbst>
probably share contexts
<karolherbst>
there is this thing in GL
<karolherbst>
it's more part of GLX and EGL
<karolherbst>
cl_khr_gl_sharing
<karolherbst>
ehhh
<karolherbst>
that's the cl ext
<karolherbst>
anyway, doesn't matter
<karolherbst>
the CTS does have tests though, and I hope they work
<karolherbst>
okay.. "cl_khr_mipmap_image" is an extension on its own, that's a relieve
<karolherbst>
that brings lod to CL obviously
<karolherbst>
jekstrand: we really have to improve compilation times though
<airlied>
karolherbst: how you seeing lp_fence_create being hit with compute paths?
<karolherbst>
airlied: by flushing?
<karolherbst>
dunno.. maybe it was just noice, but tsan and libasan pointed out there is a race
<karolherbst>
and it kind of looks racy
<airlied>
yeah it's just not a path the compute should need to hit, I probably should fix it to avoid that
<karolherbst>
why not though?
<airlied>
the fences are only for fragment shader
<karolherbst>
ahh
<karolherbst>
I see
<karolherbst>
so context flushes use something else?
<airlied>
compute doesn't overlap
<airlied>
I should fix that also :-P
<karolherbst>
:D
<karolherbst>
I still do image stuff though
<karolherbst>
also
<karolherbst>
gl sharing
<airlied>
currently it syncs all the threads at the end of execution
<airlied>
yeah like blitting could hit the frag path
<karolherbst>
see :P
<karolherbst>
anyway, once we start importing GL objects, stuff will get interesting
<karolherbst>
what the hell is this ext
<karolherbst>
of course it allows to import every possible GL texture target
<karolherbst>
clCreateFromGLRenderbuffer okay...
<karolherbst>
cl_khr_gl_event :O
<karolherbst>
oh no, that exist as well
<karolherbst>
this is so cursed
<karolherbst>
cl_khr_gl_msaa_sharing is fun as well
<karolherbst>
and cl_khr_gl_depth_images :)
<karolherbst>
they just went all out on that, didn't they?
<karolherbst>
it's fun that all the official extensions put together are bigger than the CL spec
<javierm>
danvet, tzimmermann: commit aafa025c76dc ("fbdev: Make fb_release() return -ENODEV if fbdev was unregistered") was already sent to torvalds for 5.18-rc6
<javierm>
or just to drm-misc-next and target 5.19 ?
<tzimmermann>
javierm, i'd push it to misc-fixes
<airlied>
yeah so would I :-)
<javierm>
airlied, tzimmermann: Ok!
mvlad has joined #dri-devel
<tzimmermann>
javierm, you could also push the actual patches into -fixes
<tzimmermann>
so the bug gets resolved
<javierm>
tzimmermann: yes, that's why I said the revert + the series (fixing properly in the drivers)
<tzimmermann>
ah, that was the url
<javierm>
tzimmermann: yeah
<danvet>
tzimmermann, javierm yeah the actual patches need to go into -fixes too
<danvet>
because they're fixing a regression
dllud has quit []
<javierm>
danvet: yes, I just wondered if it was too much churn for at this stage of the -rc cycle and we wanted to just keep the original attempt (although not completely correct) for 5.18
<javierm>
but thanks for the clarification, I'll just push everything then to -fixes. I guess is OK to do it already since all patches are reviewd by thomas and you
<danvet>
javierm, I'm worried that the original attempt causes too much issues
<danvet>
it's really rather wrong
<javierm>
danvet: it is, I agree but "just" causing leaks rather than a crash
<javierm>
anyway, just wanted to double check with you because wasn't sure how to proceed
<airlied>
robclark: I assume dimitry prs are targeted at you not me?
dllud has joined #dri-devel
OftenTimeConsuming is now known as Guest242
OftenTimeConsuming has joined #dri-devel
Guest242 has quit [Ping timeout: 480 seconds]
<javierm>
danvet: all pushed to -fixes now. Thanks a lot again for your help with this bug
<danvet>
np
lynxeye has joined #dri-devel
lemonzest has joined #dri-devel
famfo has quit []
Guest205 is now known as go4godvin
famfo has joined #dri-devel
rasterman has joined #dri-devel
maxzor has joined #dri-devel
<emersion>
javierm: congrats on the maintainership :)
<javierm>
emersion: thanks :)
pcercuei has joined #dri-devel
apinheiro has joined #dri-devel
frankbinns has joined #dri-devel
<jadahl>
emersion: does wlroots do FB_DAMAGE_CLIPS?
<emersion>
yes
<jadahl>
neat, then you'll get to enjoy the mgag200 improvements that is coming
<emersion>
ahah nice
<daniels>
the weston-on-mgag200 userbase will also be thrilled
<javierm>
daniels: it seems matrox cards is what all cool people have these days :)
hansg has joined #dri-devel
<jadahl>
one day steam will add matrox to min-spec section and they will be even more thrilled
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
heat_ has joined #dri-devel
heat_ has quit [Remote host closed the connection]
gpiccoli has quit [Quit: Bears...Beets...Battlestar Galactica]
gpiccoli has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
jewins1 has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
lumag_ has joined #dri-devel
Danct12 has quit [Quit: Leaving]
jimjams has quit [Quit: Connection closed for inactivity]
Haaninjo has joined #dri-devel
flacks has quit [Quit: Quitter]
AndrewR has joined #dri-devel
<AndrewR>
karolherbst, imirkin - hello!
flacks has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
jkrzyszt 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]
ahajda has quit [Ping timeout: 480 seconds]
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 quit [Remote host closed the connection]
itoral has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
ahajda 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
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
nchery has quit [Read error: Connection reset by peer]
<karolherbst>
so I guess for cl_khr_gl_sharing, if I get the GLXContext/EGLContext and the Display/EGLDisplay, I need to get the dri_context from that to access st/mesa stuff, correct?
<karolherbst>
although not quite sure if that helps, because I get essentially the GL values for everything
<karolherbst>
should probably check out include/GL/mesa_glinterop.h
<karolherbst>
mhh, seems like that's using dmabuf
<karolherbst>
which is probably the correct thing to do, because GL and CL live in different dlopen instances and I can probably not share pointers anyway
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
itoral has quit [Remote host closed the connection]
apinheiro has quit [Ping timeout: 480 seconds]
<vsyrjala>
javierm: danvet: tzimmermann: i915 ci on fire due to some efifb oops. looks like it's trying to eat poison
<ajax>
karolherbst: "separate dlopen instances"?
<karolherbst>
well, I mean, they could both be dlopened
<ajax>
they'd still be in the same process address space
<karolherbst>
sure, but things are weird if you start passing things around
<ajax>
not really, no
<ajax>
not unless you're using dlmopen, and nobody does
<ajax>
you can call a function pointer in A from B even if both were RTLD_LOCAL
<karolherbst>
well, we already had enough fun with passing nir_shaders between clover and drivers, because the glsl_type pointers were all wrong
<javierm>
vsyrjala: hmm, do you have a boot log to look at ?
<karolherbst>
ajax: anyway, we already have things like MesaGLInteropGLXQueryDeviceInfo
<karolherbst>
but somehow I am not able to link to that as this lives inside libgl :(
<karolherbst>
ohh.. wrong order inside meson
<karolherbst>
now that's annoying
<javierm>
vsyrjala: gah, it's a bug with my latest "fix"
mclasen has joined #dri-devel
<javierm>
I wonder why it wasn't happening before though since the fb_info was freed in .remove and release_mem_region() done in .fb_destroy, that part didn't change
<vsyrjala>
i guess no cc:intel-gfx when patches got posted since this slipped through? sadly we don't have the ci bandwidth to test everything on dri-devel :(
<javierm>
vsyrjala: I tested locally though, but I guess that nothing was holding a fbdev fd and so fb_destroy() didn't happen after a remove()
<javierm>
vsyrjala: if I post a patch and Cc intel-gfx it will be tested then? Or can we run a test with drm-misc-fixes + a patch ?
<vsyrjala>
everything posted to intel-gfx will get tested
<javierm>
vsyrjala: Ok, thanks. I'll Cc then
<karolherbst>
cool, it works now :)
<karolherbst>
ehhh
<karolherbst>
how does all of the PCI stuff look on most of the SoCs? Are the GPUs generall always exposed as PCIe devices, or are there also some where this isn't the case?
<karolherbst>
mhh... well it's not on tegra anyway, so I doubt it's the case on others
<lynxeye>
karolherbst: On most SoCs the GPUs are on a non-discoverable bus.
<karolherbst>
right...
<karolherbst>
now that's annoying.. maybe, I am not sure yet
<karolherbst>
so we do use dmabufs for CL/GL sharing, and I was wondering if I have to make sure if the GL context is on the same device as passed into clCreateContext
<javierm>
vsyrjala: patch posted. Sorry about the mess...
<javierm>
can't believe I missed that
<lynxeye>
karolherbst: If you use dma-bufs that shouldn't matter.
<karolherbst>
yeah.. probably not
<karolherbst>
I am just wondering how efficient that is if it's all on the same device
<karolherbst>
or is that fine as well?
gawin has joined #dri-devel
<lynxeye>
Other than the slight overhead of the fd it shouldn't matter. Kernel driver should be able to figure out that the dma-buf is from the same device and keep it in local memory.
<karolherbst>
okay
<karolherbst>
then let's see if I can make that actually work then
<lynxeye>
In fact if you do the dance gem handle -> prime fd export -> prime fd import -> gem handle you get back exactly the same gem handle/bo
<lynxeye>
On the same device that is
<robclark>
airlied: yup, there're for me
<MrCooper>
technopoirot: cool
oneforall2 has quit [Remote host closed the connection]
<tagr>
karolherbst: if I recall correctly some of the x86 SoCs expose PCI devices, which might be emulated, and possibly some of the ARM server SoCs might as well, but I don't think it's something that is generally done
<MrCooper>
lynxeye: to be pedantic, that's assuming the prime export & import both use the same DRM file description; otherwise if it's the same device, you get a different GEM handle, which references the same BO though
<karolherbst>
tagr: yeah... well.. best case it doesn't matter. It just sounds like that this interop stuff was written with "you use the gl context from the same device" in mind
Danct12 has joined #dri-devel
<karolherbst>
at least some comments make it sound like it
oneforall2 has joined #dri-devel
<tagr>
yeah, there are a lot of those kinds of assumptions, basically similar to the whole "display and GPU will always be the same device" assumption that every SoC has been trying to comply with
rgallaispou1 has joined #dri-devel
AndrewR has quit [Ping timeout: 480 seconds]
rgallaispou1 has quit [Read error: Connection reset by peer]
<tagr>
MrCooper: I think most drivers actually check for struct drm_device, so even if you try to export/import between two file descriptors that reference the same device it should give you the exact same GEM handle
rgallaispou has quit [Ping timeout: 480 seconds]
<MrCooper>
tagr: same BO, but every DRM file description has its own GEM handle namespace
rgallaispou has joined #dri-devel
<tagr>
MrCooper: oh right... GEM is what I meant, not GEM handle, and yeah, that's exactly what you said /o\
Danct12 has quit [Remote host closed the connection]
whald has joined #dri-devel
technopoirot has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
<whald>
hi! i have a somewhat interesting problem with my application running on an Intel Gen9 GPU: i'm trying to drive a 4k60 display, preferably at 60fps. as it stands, rendering a frame takes 18.4ms so i'm missing every other frame. thing is, the GPU is running at only 500MHz and according to Intel GPU top is utilized to only 55%. so I think it would be possible to hit 60fps, but that thing refuses to clock up.
<whald>
fun thing is that loading the video decode unit some more does cause it to clock up, then hitting the 60fps no problem. is there anything sensible I can do about this?
<ajax>
whald: i think there are some clock tuning parameters in /sys/class/drm/card*/ for this. my coffeelake has a writeable file there named gt_min_freq_mhz
AndrewR has joined #dri-devel
ella-0_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<ajax>
ugh. src/gallium/frontends/dri/ has files named all of utils.c, dri_util.c, and dri_helpers.c
<ajax>
very helpful, much utility
devilhorns has joined #dri-devel
<whald>
ajax, I should have mentioned that I already stumbled upon the /sys/class/drm/ stuff, but wrinting to gt_min_freq_mhz has little to no effect. :-(
<ajax>
aw
<whald>
"gt_max_freq_mhz" says 900, which is the same I wrote to "gt_min_freq_mhz" (and I can read back that value, so it was accepted). but intel_gpu_top still says ~500
ella-0 has quit [Read error: Connection reset by peer]
PoChen_ has joined #dri-devel
kts has joined #dri-devel
PoChen_ has quit []
tzimmermann has quit [Quit: Leaving]
rxbcchen has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
AndrewR has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
mclasen has joined #dri-devel
<karolherbst>
k.. clCreateFromGLTexture
<karolherbst>
that's gonna be fun
gawin has joined #dri-devel
AndrewR has joined #dri-devel
jfalempe has quit [Quit: Leaving]
<anholt>
zmike: different circumstances, but some explanation on 3c0e4be89bd43c4ffa970f86b14765c5f518aa13
<zmike>
huh
nchery has joined #dri-devel
<jekstrand>
danvet: Went to re-up my IGT tests for dma-buf sync_file import/export and I'm wondering what we want to do around testing import.
<danvet>
jekstrand, hm why?
<jekstrand>
danvet: The previous tests tested the "it's always exclusive" behavior where setting the fence would also gather up all the read fences.
<jekstrand>
But now that we're just throwing one in the bucket, that's not how it works anymore.
<danvet>
well, more complicated
<danvet>
if you throw in a write fence
<danvet>
and then export again for write access you'll get write+read fences
<danvet>
so it still gathers them all up
<jekstrand>
export does, yes.
<danvet>
but a subsequent read will only gather up the write fence and the readers are just whatever
<danvet>
so I guess test the above gather but not the old gather behavour due to the exclusive slot stuff
<jekstrand>
But if one of your write finishes before some reads that are there (because userspace isn't actually required to wait on the reads, which is fine) then it'll go back to POLLIN being non-busy.
<jekstrand>
Which, again, is fine. We're technically poking at the case where userspace raced with other userspace.
<danvet>
hm
<danvet>
yeah that needs to be all adjusted
<danvet>
or you keep the write fence unsignalled
<danvet>
or change that testcase to use POLLOUT to validate that we still gather all read+write fences for that case
<jekstrand>
I think the behavior we have is fine. Non-racy userspace will wait on all the read fences before signaling its write fence.
<danvet>
oh yeah it should all work
<jekstrand>
The question is how we test.
<danvet>
plus with gl cs ioctl the kernel will do that ordering/waiting for you
<jekstrand>
I've got a "basic" test which sets a fence in all three modes (READ, WRITE, RW) and tests that things are appropriately busy.
<danvet>
this is just more rope for vk clients to amuse themselves with :-)
dllud has quit [Ping timeout: 480 seconds]
<jekstrand>
Trying to figure out if we really need more.
dllud has joined #dri-devel
<danvet>
jekstrand, yeah I'd do one that adds a read and write fence
<danvet>
and then validates the gather of POLLIN
<jekstrand>
I guess maybe a multi-import test too?
<danvet>
I think that's really the only case we care about
<danvet>
yup
<jekstrand>
Ok, I'll type up a multi-import test and call it good.
<jekstrand>
And send new IGTs
<danvet>
and I guess do both cases, i.e. write fence completes before read fence and other way round
<jekstrand>
Sure
<danvet>
and check that both POLLIN&OUT all work like we expect them too for that multiimport case
<danvet>
I think then we have this fully nailed
<danvet>
and it's a nice cross-check that dma-buf poll works too
<jekstrand>
I've already got tests as part of the export group that test that export correctly gathers everything at the time of export and nothing after.
<danvet>
well that's separate code, so I think good to test both
<jekstrand>
sure
<danvet>
both = poll on dma-buf and poll on exported sync_file
<jekstrand>
Yeah, that's what I've been doing. I've got helpers for doing it both ways and check both
<danvet>
I mean 10+ years later and we finally have well defined implicit sync with testcases even, yay
<danvet>
perfect
<jekstrand>
lol
gouchi has joined #dri-devel
gouchi has quit []
heat has quit [Remote host closed the connection]
jimjams has joined #dri-devel
heat has joined #dri-devel
<karolherbst>
nice...
<karolherbst>
it works :)
<karolherbst>
dmabuf_fd: 0xb,
<karolherbst>
internal_format: 0x8058,
<karolherbst>
:3
<karolherbst>
now I just need to make use of it
<karolherbst>
guess I need to use pipe_screen::import_memory_fd and pipe_screen::resource_bind_backing
<karolherbst>
and it seems like map/unmap is a little special as well
<karolherbst>
or could I use resource_from_handle?
kts has quit [Quit: Konversation terminated!]
<MrCooper>
for a dma-buf fd, yeah that should work I think
mclasen has quit [Ping timeout: 480 seconds]
<karolherbst>
let's how. dealing with plain pipe_memory_allocation looks a bit annoying
<karolherbst>
*hope
lina has joined #dri-devel
mclasen has joined #dri-devel
stuart has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
<jekstrand>
danvet: Weird process question. With the kernel, should I also add a S-O-B with my collabora e-mail address?
* danvet
shrugs
<jekstrand>
It's still me either way saying "it's all good"
<karolherbst>
don't we have mailmap for that?
<danvet>
yeah lwn maintains a mailmap for this anyway
<danvet>
some people add their current employer in ()
<danvet>
jekstrand, I guess for these patches you'd need both intel and collabora sobs
<danvet>
so maybe make it 3 for lolz?
<jekstrand>
danvet: Sure! Why not!
<jekstrand>
Or maybe just two: Intel and collabora
<jekstrand>
idk
<danvet>
roll a dice
<jekstrand>
hehe
<danvet>
so the only thing tooling checks is that you have a sob that matches your author line
<jekstrand>
Ok
<jekstrand>
I'll do all three then
<jekstrand>
woo
<mareko>
can we require zstd by default?
<jekstrand>
Windows? Though I see no reason why windows can't build it too.
<jekstrand>
I wouldn't be opposed. It'd be a lot easier if we could assume it.
Danct12 has quit [Ping timeout: 480 seconds]
<daniels>
Windows already has to build zlib, so it can sure build zstd as well
<jekstrand>
I guess type the MR, make sure you CC ajax and tjaalton, and see if anyone complains?
<ajax>
curiously the only package in my mesa dev toolbox that requires zstd already is rpm-build
<jekstrand>
lol
<ajax>
but my silverblue host seems to already have it installed so thumbs up from me i think
lumag_ has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
technopoirot has joined #dri-devel
<jekstrand>
danvet: What should we do about the copy_to_user?
<jekstrand>
danvet: I've typed a version that cleans up the sync_file if it fails.
<jekstrand>
König gave that as an example of something that returns an FD but it doesn't, actually.
<jenatali>
Does Windows have zstd? I've never looked
<jekstrand>
jenatali: zstd can build on Windows
<jenatali>
Cool. Then yeah no complaints from me
<jekstrand>
jenatali: It's even got a meson build system so we can wrap it
<jenatali>
Ooh fancy
<danvet>
jekstrand, yeah cleaning up looks a tad cleaner
<danvet>
but e.g. with all drm ioctls we just don't, because the copy_to_user happens in drm_ioctl()
<danvet>
and that just fails and bails out and so leaks
<jekstrand>
danvet: Yeah...
<danvet>
so if you feel like shuffle the code, but it really doesn't matter I think
<jekstrand>
I've got a shuffle. Waiting for my machine to reboot so I can run the IGTs again
<jekstrand>
And maybe test Mesa quick
<jekstrand>
bnieuwenhuizen: Did you have a patch for me to grab that uses the import in Mesa?
<karolherbst>
marex: but that's not doing anything, is it?
<karolherbst>
we still need the code to wire up all the compiler and runtime bits
<karolherbst>
and glxinfo doesn't seem to list it
<marex>
that's right :)
<karolherbst>
it's probably easy to add support for it, but I suspect nobody did the work yet
<marex>
I really just want a simple test for texture2DGradARB , for gles2 if possible
<marex>
the piglit test is rather complex
lemonzest has quit [Quit: WeeChat 3.4]
<karolherbst>
uhhh
<karolherbst>
okay.. I think the current interop interfaces are not enough for that stuff here :(
<karolherbst>
unless I want to make it super painful
<karolherbst>
so with CL I don't know how big the resources is I want to import
<karolherbst>
and the API kind of expect me to
technopoirot has quit [Ping timeout: 480 seconds]
<karolherbst>
mhh unless I can query that stuff from an OpenGL API
<karolherbst>
guess I have to do some glGetTexLevelParameteriv calls then...
<karolherbst>
huh.. but I can't do it because I don't want to mess with the current gl state
<karolherbst>
or should those calls work regardless of what's the current context?
<ajax>
i don't understand the question?
<ajax>
gets don't have side effects, they just read out the current context state
<karolherbst>
ajax: soo. from a CL perspective I have the display, the context, the texture_target and the texture
<karolherbst>
ajax: right.. but do I have to switch to a context before using it or can I expect the given texture gives me the correct result no matter which is the active context?
<karolherbst>
or would I have to switch to the context I've gotten from the application to make sure it's all correct?
<ajax>
texture names are per-context. you need to already have a current GL context for GetTexLevelParameteriv (or anything else) to work
<karolherbst>
well
<karolherbst>
I don't want to switch the context for obvious reasons
devilhorns has quit []
<karolherbst>
so I am screwd, right?
<ajax>
i'm not entirely sure what scenario you're describing here but in what world are you trying to do CL/GL interop where the app doesn't already have a GL context to work with
<karolherbst>
the question is I think, if I can just switch gl contexts without having to worry I mess anything up
<karolherbst>
can't use it if I don't make the handed in context current, right? (and probably have to switch back to whatever was current before me messing with it)
<ajax>
clCreateFromGLTexture takes the texture name as input, right?
<karolherbst>
yes
<ajax>
which, again, only has any meaning relative to a specific GL context
<karolherbst>
correct
<karolherbst>
so I have to make the given context current, no?
<ajax>
so you would _have_ to have already set the GL context, from the app side
<karolherbst>
why would I?
<ajax>
otherwise the cl would have no idea which context to look the texture up in
<karolherbst>
the app can have a different context current
<karolherbst>
ajax: the context is also passed in
<karolherbst>
but it's attached to the cl_context
<ajax>
the CL context
<ajax>
which is orthogonal to the GL context
<karolherbst>
the cl_context has a gl context bound
<karolherbst>
which is passed in when creating the cl context
<ajax>
ick okay
<karolherbst>
currently I use MesaGLInteropGLXExportObject/MesaGLInteropEGLExportObject to create the dmabuf handle
<ajax>
so the answer then is once you're far enough into the gl implementation you can just call through ctx->blah() to dispatch things directly to that context, regardless of which thread its bound to
<karolherbst>
and the docs specify I should pass in the sizes thorugh out_driver_data, but... I don't know the sizes
<karolherbst>
right...
<karolherbst>
so that would be an alternative way if I don't want to use dmabuf, but just getting our internal stuff direcly
<karolherbst>
but it seems like the GL context doesn't have to match the devices of the cl context
<karolherbst>
it's all pretty wild somehow
<ajax>
i'm not seeing the bit of the extension that talks about how to name the gl context at cl ctx creation
<karolherbst>
"10.5. Additions to Chapter 4 of the OpenCL 2.2 Specification"
<karolherbst>
linkmauve: I guess GLFW_PLATFORM_NULL is what you meant?
<linkmauve>
There is no GLFW_PLATFORM_OSMESA it seems, so perhaps?
<linkmauve>
Perhaps GLFW_PLATFORM_NULL with GLFW_OSMESA_CONTEXT_API?
<karolherbst>
probably
<karolherbst>
at which point using SDL2 is easier :P
<karolherbst>
honestly, we should come up with a "trash osmesa" plan
<mi6x3m>
so far I'm trashed because i don't know how to tell if it works :/
<mi6x3m>
like simple smoke testing
<karolherbst>
schrödinger's osmesa
<linkmauve>
karolherbst, oh, SDL2 also supports OSMesa?
<karolherbst>
linkmauve: no, but it natively supports rendering on a tty with gbm
<karolherbst>
"it just works"
<linkmauve>
Sure, but that’s not a way to test OSMesa.
<karolherbst>
my idea of fixing that is to stop caring about osmesa and trash it :)
<karolherbst>
wouldn't have this problem to begin with then
<linkmauve>
karolherbst, you can use GLFW_OSMESA_CONTEXT_API with any platform actually, X11, Wayland, Null, even Cocoa and Win32.
<karolherbst>
cool
<karolherbst>
I guess if you use glfw then that's a solution
<karolherbst>
but yeah.. on my system wine is the only active user of it...
<linkmauve>
mi6x3m, ↑
<karolherbst>
I am tempted...
<linkmauve>
karolherbst, what does it use it for?
<mi6x3m>
linkmauve, hmmm it's better than nothing i guess
<karolherbst>
linkmauve: no clue.. let me check
<karolherbst>
dibdrv?!? what the hell is that
nchery has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<karolherbst>
linkmauve: seems like it's used only for dibdrv which looks like some win 95 era API used by paint
<karolherbst>
win 3.1 actually
apinheiro has quit [Quit: Leaving]
<linkmauve>
Just checked in PyTouhou, it does use osmesa properly after I added the context API hint. :)
dllud has quit [Remote host closed the connection]
dllud has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
<jekstrand>
bnieuwenhuizen: Ok, now I'm more confused. You can pass VkSampleLocationsInfoEXT as a chain-in on VkImageMemoryBarrier2 but how do you transition between two sets of sammple locations?
<bnieuwenhuizen>
oh I'm not sure you can
<bnieuwenhuizen>
just that sometimes the layout transitions needs the sample locations
<jekstrand>
bnieuwenhuizen: So what if subpass 0 and subpass 1 use different sample locations?
dllud has joined #dri-devel
<jekstrand>
Hrm... Looks like pAttachmentInitialSampleLocations is only for subpasses which aren't used for rendering.
<jekstrand>
Ok, I can work with that.
mi6x3m has quit [Quit: Leaving]
<jekstrand>
bnieuwenhuizen: Reading the spec, I see no reason why two subpasses can't use different sample locations. :-/
<bnieuwenhuizen>
jekstrand: I think that is supposed to be allowed. (see variableSampleLocations)
<bnieuwenhuizen>
I'm guessing the same HW that needs it during layout transitions can't support that feature?
<jekstrand>
bnieuwenhuizen: variableSampleLocations allows you to switch within a subpass
<jekstrand>
Nothing prevents you from switching between subpasses AFAICT
<jekstrand>
bnieuwenhuizen: I guess we could transition to general and back to switch sample locations?
<jekstrand>
Seems sketchy
<bnieuwenhuizen>
can't you do an identity transition?
<bnieuwenhuizen>
hmm, I guess we don't have src/dst locations
<jekstrand>
I can only specify one set of sample locations in a image barrier
<jekstrand>
yeah
<bnieuwenhuizen>
I guess I have to dig into how AMD HW works at some point
<jekstrand>
:-/
<bnieuwenhuizen>
since AFAIU part of the idea was that our depth compression can kinda do a plane, which is hence dependent onsample locations
<jekstrand>
Yeah
<jekstrand>
The HW may want them sorted in a particular order
<bnieuwenhuizen>
but I have no clue why compressed texture sampling works without having a clue about locations at all
<jekstrand>
Is it only depth/stencil that cares?
<bnieuwenhuizen>
yeah, color definitely doesn't on our HW
<jekstrand>
That makes sense. I think AMD's MSAA compression is simliar to Intel and Intel's is pure index-based.
<jekstrand>
But I could easily see depth being weirdly special.
<bnieuwenhuizen>
also from the extension description: "Some implementations may need to evaluate depth image values while performing image layout transitions. "
<bnieuwenhuizen>
with that + layout transitions I can see this being so targetted at AMD
icecream95 has joined #dri-devel
<jekstrand>
I'm going to write a bug and assign it to tobias
<bnieuwenhuizen>
oh from the extension text: "Modifying the sample locations causes the reconstruction to no longer evaluate the same depth values as when the samples were originally generated, thus the depth aspect of a depth/stencil attachment must be cleared before rendering to it using different sample locations."
<bnieuwenhuizen>
now to find where they say that in the main spec
<jekstrand>
Oh, that helps!
<bnieuwenhuizen>
and all the renderpass/subpass info seems mostly to aid in the pre-existing layout transitions then
<jekstrand>
Yup. I think so.
<jekstrand>
If you're required to clear before switching locations, I think that takes care of everything.
<bnieuwenhuizen>
... and since dynamic rendering has no transitions it has no interactions with the sample locations ext
<bnieuwenhuizen>
(or I forgot something about resolve)
<jekstrand>
Yup. We'll chain a SampleLocationsInfoEXT into the BeginRenderingInfo for you.
<jekstrand>
Of course it doesn't interact properly with multiview... :facepalm:
<daniels>
karolherbst: btw you mean surfaceless rather than gbm
<karolherbst>
daniels: ehhh... right
<karolherbst>
although I thoguht that was using gbm? but maybe I am confusing that with whatever deqp or piglit call it
<karolherbst>
ahh the platform is called EGL_PLATFORM_SURFACELESS_MESA
<karolherbst>
guess we might want to deprecate osmesa and say "use EGL_MESA_platform_surfaceless"
<karolherbst>
anyway
anholt_ has joined #dri-devel
anholt has quit [Ping timeout: 480 seconds]
tursulin has quit [Remote host closed the connection]
<karolherbst>
first cl_mem created from an imported GL texture :)
mszyprow_ has quit [Ping timeout: 480 seconds]
<jekstrand>
bnieuwenhuizen: I think I've got something plausible:
<jekstrand>
And it's 6:15 PM here so I think I'm going to call it a week-end. I'll try to pick up the remainder of the RADV rewrite next week in-between F2F meetings.
ppascher has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
mattrope has quit [Remote host closed the connection]