ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<anholt> I could imagine a request with 2560xwhatever with a modifiers list of (modifier, linear), and you check if modifier at that width is hopeless
<anholt> and fall back to linear
<daniels> yep
<daniels> which can only work if you a) know about the display controller (Panfrost cannot, or we might as well delete kmsro), and b) know about the width (which this patch precludes)
nchery is now known as Guest124
nchery has joined #dri-devel
<daniels> so what I'm suggesting is to keep the concept of kmsro, to not lie to kmsro about what you're asking it to do, and if kmsro is somehow inadequate (the commit message & MR do not explain how it's inadequate), to improve it so that it works
<anholt> a new entrypoint for kmsro with enough args in it to do addfb2 (for example) seems plausible, and you'd still have panfrost doing layout
<anholt> for modifiers
<daniels> either that or pull the compatibles and filter based on that
<daniels> I don't mind which - my objection is keeping kmsro as an interface and cargo-culting 1024 as the accepted width everyone lies to it with
<anholt> as kmsro has grown, I've thought about going back to it and cleaning it up. would really need to break out the rpi with the spi displays to torture it, though.
<daniels> absolutely no objection to that ...
morphis has quit [Ping timeout: 480 seconds]
<daniels> it's not the best interface for sure. but keeping the existing interface as if it came from Mount Sinai and coming up with agreed-upon lies seems objectively worse
morphis has joined #dri-devel
Guest124 has quit [Ping timeout: 480 seconds]
hch12907 has joined #dri-devel
jewins has quit [Remote host closed the connection]
jewins has joined #dri-devel
Company has quit [Quit: Leaving]
<airlied> jekstrand, karolherbst : i think they are considering a sycl backend
<airlied> in blender
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
CATS has quit [Ping timeout: 480 seconds]
CATS has joined #dri-devel
jimjams has joined #dri-devel
camus has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
consolers has joined #dri-devel
bewitched has joined #dri-devel
consolers is now known as Guest135
bewitched is now known as consolers
maxzor has joined #dri-devel
Guest135 has quit [Ping timeout: 480 seconds]
<consolers> so with matrix, there is no notification that the message you sent through the irc has been dropped
<HdkR> yep
poirot has joined #dri-devel
poirot has quit [Killed (NickServ (Too many failed password attempts.))]
poirot has joined #dri-devel
poirot is now known as technopoirot
heat_ has quit [Remote host closed the connection]
<technopoirot> if X receives a dri3_pixmap_from_buffers call and binds a framebuffer to that pixmap's texture, how does it know if the texture has been updated from the client?
heat_ has joined #dri-devel
<technopoirot> I have glamor configured with modesetting, and either the texture's fbo or the screen's fbo isn't getting updated properly when the client calls CopyArea
<jekstrand> airlied: That'd be neat, probably.
<jekstrand> It doesn't
<jekstrand> technopoirot: ^^
<jekstrand> technopoirot: It just creates a pixmap that you can then use to either present or use as a copy source.
<jekstrand> technopoirot: You're responsible to render and then do one of those two and then not touch it again until you get a release.
<jekstrand> With present, there are also these shmfence things that you have to manage as part of the present/release process.
<technopoirot> jekstrand: thanks. sorry, newb here. wdym by release? does that only apply in the present case or also to CopyArea requests?
<technopoirot> I have a basic configuration with bare Xorg and I'm attempting to run glsync
<technopoirot> I get the first frame (red rect), but color never changes on the display panel
<technopoirot> I've been able to "force" a swap by alternating the src and dst parameters in the client's CopyArea call, but it's not clear to me why this works.
<technopoirot> I assumed Xorg was failing to see the updated texture from the client, but maybe it's failing to copy from the client's pixmap fbo to the screen fbo?
consolers has quit [Ping timeout: 480 seconds]
<technopoirot> I feel pretty sure the issue is some interaction with glamor and our gpu stack (etnaviv), because I can set Option "AccelMethod" "none" in xorg.conf and everything looks correct
<imirkin> that's like saying "all my simd problems are solved if i disable sse"
mclasen has quit [Ping timeout: 480 seconds]
<technopoirot> imirkin: well, I can run the exact same mesa and xserver code and configuration on another platform and glsync works correctly with that gpu (vc4)
<technopoirot> it's not like I'm trying to blame my ethernet stack
<imirkin> :)
<imirkin> and there could well be an issue with that stack. but accelmode = none probably disables dri3 in the first place
<imirkin> and if it doesn't, it's a mere shell of what it is with a "proper" gpu
<imirkin> if you're doing stuff "out of spec", then just because it works in one place doesn't mean it's legal
<imirkin> (i'm not completely sure what you're doing, but just saying that the "but it works on nvidia" argument is a weak one)
<technopoirot> I don't think I'm doing anything out of spec, like I said just trying to run Xorg (glamor+modesetting specifically) and glsync on this platform
<imirkin> what's "glsync"?
<technopoirot> glsync is a mesa demo
<imirkin> ah
<technopoirot> I can run it successfully on this platform using a DDX driver, but I think it's DRI2
<imirkin> could be the demo doing something dodgy
<imirkin> let's see
<imirkin> where is the demo in the demos package?
<imirkin> nm, found it
<technopoirot> your point about dri3 and accelmode = none is valid. I assumed the client would be calling the same interfaces but I need to confirm that
<technopoirot> src/xdemos/glsync.c
<technopoirot> I'm running it without any arguments, just trying to verify basic functionality here
<imirkin> k
<imirkin> and what's happening?
<technopoirot> I get a red 500x500 rectangle, and that's it
<imirkin> it never turns white?
<technopoirot> nope
<imirkin> "but it works on nvidia" :)
<technopoirot> I never said "nvidia" :)
<imirkin> i did. i have an nvidia board plugged in
<imirkin> (with nouveau)
<technopoirot> I can force it to white sometimes if I stop the client before the xcb_copy_area call and reverse the src and dst
<imirkin> does forcing dri2 make it work?
<imirkin> LIBGL_DRI3_DISABLE=1
<technopoirot> let me double check
<technopoirot> on client, server, or both?
<imirkin> in the env var of the running application
<imirkin> i.e. the X client
<technopoirot> no, in fact I don't even get the red rectangle when I do that
<imirkin> super.
<imirkin> what happens if you add "-s b"?
<imirkin> (strobe warning)
<imirkin> this makes it use glXSwapBuffers which is what it _ought_ to be doing in the first place
<imirkin> i.e. "./glsync -s b" or whatever
<technopoirot> still nothing with LIBGL_DRI3_DISABLE=1, but -s b does work in dri3 mode
<imirkin> hm
<imirkin> dri2 being busted is definitely curious
<imirkin> that means the server-allocated buffer is never getting filled
heat_ has quit [Ping timeout: 480 seconds]
<imirkin> with dri3 the client is supposed to render to a buffer and then pass it via dri3 and present it
<imirkin> whereas with dri2, the server allocates the fb and the client renders into it
<imirkin> sorry, not sure what's going on
<imirkin> you have a separate display + render driver situation right?
<imirkin> all bound together with kmsro?
<technopoirot> no worries, I appreciate the feedback
<technopoirot> yes, separate display and render driver
<imirkin> ah, fun. for buffer_swap, it requests a doublebuffer visual
<imirkin> whereas with the other modes it doesn't
<imirkin> iirc dri3 is pretty weird about frontbuffer rendering
<imirkin> the fact that nothing works with dri2 is the most surprising of all, but it could be some kmsro thing i'm not familiar with
<technopoirot> can you elaborate on the "weird about frontbuffer rendering"?
<imirkin> iirc it just plain didn't work for a long time. i do seem to recall someone eventually made it work.
<imirkin> these are faint recollections though
<imirkin> could have been variously limited to swrast
<imirkin> airlied might remember?
<imirkin> not sure your knowledge of various GL jargon, but frontbuffer rendering = render to GL_FRONT or to a winsys visual which isn't double-buffered
<technopoirot> I have spent quite a bit of time poking around both xorg and mesa code using gdb, but I'm by no means an expert
<technopoirot> I have noticed that glsync is only using a front attachment, not sure if that loosely corresponds to the front buffer?
<imirkin> 100% corresponds to that
<imirkin> and definitely don't worry about left vs right
<technopoirot> k, just making sure I wasn't assuming things about terminology
<imirkin> if you ever see like GL_LEFT_ATTACHMENT or whatever
<imirkin> that's an ill-conceived attempt at supporting 3d monitors
<technopoirot> I think my platform is additionally complicated by the fact that the scanout buffer and render buffer have to be different formats (linear vs. tiled)
<imirkin> ah right
<imirkin> so then something has to make that copy
<imirkin> and maybe it's not making that copy in the dri2 case for some reason?
<imirkin> the _usual_ thing is that dri2 allocates a linear thing that can be scanned out, and then the client renders into that
<technopoirot> ah yes that could be
<technopoirot> there is an implicit flushing mechanism that was added to support this copy, which I _think_ is working but maybe not for dri2 for some reason?
<imirkin> yea dunno
<imirkin> austriancoder can probably say a word or two about etnaviv
<technopoirot> but if I understand correctly I think the implicit flush is just the copy from the tiled render buffer to the linear scanout in the client resources
<technopoirot> it's not quite clear to me which of those relates to the xcb_copy_area request from the client
<technopoirot> I think the drawable id used as the src is tied to the buffer allocated by dri3_alloc_render_buffer, but I'll have to go back and check my notes on exactly which format that is
<imirkin> xcb_copy_area is going to be from the dri3-backed pixmap
<imirkin> so whatever you present'd
<imirkin> in case you don't know about it, there's a "xtrace" which can provide some clarity
<imirkin> (sometimes called x11trace)
<technopoirot> right, and I think that's backed by a linear formatted buffer iirc. does that seem to make sense?
<imirkin> that'd be unusual
<technopoirot> ok haha
<technopoirot> re: xtrace thanks, I haven't seen that yet I don't think
<imirkin> the whole point of dri3 is that the client chooses optimal tiling
<imirkin> and is able to render in a more optimized manner
<imirkin> but i don't know how it plays out with kmsro + glamor
<imirkin> is it sending linear buffers? is it sending tiled buffers? dunno
<imirkin> the compositor has to compose, so it would make more sense to be sending tiled buffers so they can be used as textures
<technopoirot> well that was kind of what I thought, because glamor is binding that pixmap's texture to an fbo in order to copy it to the X window
<technopoirot> maybe I just mistraced what buffer was being loaded
elongbug has joined #dri-devel
<imirkin> it could also be that the non-optimal thing is happening :)
<imirkin> anyhoo, i'm off. hope that was at least slightly informative. good luck!
<anholt> I think all current kmsro drivers are linear only. should get sorted out, but I haven't ever had one of those platforms (mine were restricted to linear)
<technopoirot> imirkin: yes, I appreciate your time! thanks!
<anholt> but also: if you're doing X copies instead of SwapBuffers, or doing anything involving frontbuffer rendering, you really need to fix that in your app first before worrying about anything else.
elongbug has quit [Read error: Connection reset by peer]
elongbug has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
elongbug_ has joined #dri-devel
elongbug has quit [Ping timeout: 480 seconds]
elongbug__ has joined #dri-devel
elongbug_ has quit [Read error: Connection reset by peer]
tzimmermann has joined #dri-devel
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #dri-devel
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
lemonzest has joined #dri-devel
elongbug__ has quit [Ping timeout: 480 seconds]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #dri-devel
danvet has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
jagan_ has quit [Remote host closed the connection]
itoral has joined #dri-devel
tursulin has joined #dri-devel
mszyprow_ has joined #dri-devel
Daanct12 has joined #dri-devel
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #dri-devel
jkrzyszt has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<pepp> TMM: yes sorry
dj-death has quit [Ping timeout: 480 seconds]
dj-death has joined #dri-devel
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #dri-devel
lynxeye has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
thellstrom has joined #dri-devel
<javierm> danvet: hi, did anyone try to integrate patchwork with the dim workflow? It would be nice to for example use pwclient to change the pushed patches state in patchwork
<danvet> javierm, we had/have some server side hooks
<danvet> at least in drm-intel.git
<danvet> javierm, wrt patchwork I kinda gave up on that, since trying to distill meaning out of rfc822 soup is a bit too futile
<javierm> danvet: I see
<javierm> I guess also adds little value if people don't change the state for superseed / rejected patches as well
<MrCooper> technopoirot: it could be because the X server doesn't call glEGLImageTargetTexture2DOES again when it should
ppascher has joined #dri-devel
<danvet> javierm, yeah that's the thing
<danvet> with MR you can track this much easier since you don't have a pile of of old series lying around
<danvet> with patchwork it kinda works if you follow the right convention
<javierm> danvet: agreed
rasterman has joined #dri-devel
<jekstrand> anholt: FYI: I'm getting this with deqp-runner on some Vulkan CTS runs:
<jekstrand> ERROR - Failure getting run results: parsing results: unknown dEQP status 'Info' (See "results/panvk-descriptor-set-rewrite-v4/c848.r1.log"
<jekstrand> Looks like the test crashed and it's an incomplete result. That's a very weird error message for that...
jimjams has quit [Quit: Connection closed for inactivity]
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
pcercuei has joined #dri-devel
apinheiro has joined #dri-devel
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #dri-devel
<karolherbst> airlied: ahh, cool
<karolherbst> airlied: what's the best way to try out sycl?
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
<hakzsam> karolherbst: do you still plan to update https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6591 or it could be closed?
<karolherbst> good question
<karolherbst> I think it's still needed, but I don't really have an idea on how the "perfect" solution should look like
<karolherbst> hakzsam: any specific reason you are asking? If somebody else wants to give it a shoot, that's totally fine by me
<hakzsam> triaging old MRs tagged with RADV :)
<karolherbst> ahh
Daaanct12 has joined #dri-devel
Daanct12 has quit [Read error: Connection reset by peer]
<karolherbst> airlied: mind figuring out split samplers/textures based on my rusticl tree or jekstrands MR?
<karolherbst> for llvmpipe tht is
<karolherbst> although I guess the lp_sampler_static_state struct needs to be split, no?
<karolherbst> mhh
<karolherbst> maybe I see a quick fix
<airlied> karolherbst: there is no good way yet, the bad way is pretty much building intel llvm/clang forks
<airlied> karolherbst: split samplers/textures should be fine in llvmpipe
<karolherbst> yeah... although I think somebody forgets to read out num_samplers :)
<airlied> tracking > 32 is messy though due to some legacy TGSI interaction code that should probably get rewritten
<karolherbst> I'll have to dig what's going wrong
<karolherbst> anyway, I have a kernel with 1 texture, 2 images and 1 sampler
rkanwal has joined #dri-devel
<karolherbst> and it crashes because of the shader key being too small
<karolherbst> p shader->info.base.file_max
<karolherbst> $8 = {0, 0, -1, 0 <repeats 12 times>}
<karolherbst> mhh
<karolherbst> is that relevant for nir?
<karolherbst> I get the feeling it is, but.
<airlied> yeah that's the problem
<airlied> at least with > 32
<karolherbst> right...
<airlied> with less than that it should be fine
<karolherbst> it's less
<karolherbst> but
<karolherbst> shader_info got changed a lot
<airlied> the problem is llvmpipe still uses tgsi shader info for lots of things
<karolherbst> sure
<airlied> and the nir info is translated in nir_to_tgsi_info.c
<airlied> and sometimes that can have issues due to lowering removing info
<karolherbst> but we still only have 1/2/1 items here
<airlied> yeah so it might be the image info translation going wrong
<karolherbst> airlied: I am sure the issue is, that images_used is now a bitfield, textures_used is now 128 bits big and samplers_used was added :)
<karolherbst> and I don't think the MR updates llvmpipe here
<karolherbst> let's seee
preda has joined #dri-devel
<airlied> ../src/gallium/auxiliary/nir/nir_to_tgsi_info.c:803 or so
<karolherbst> yeah...
<airlied> there might be some relevant changes in my llvmpipe-cl-img-wip-2 branch
* airlied gotta go get kids to bed!
<karolherbst> have fun
* karolherbst hopes he didn't mess up
<karolherbst> seems like I didn't
mvlad has joined #dri-devel
MrCooper has quit [Quit: Leaving]
icecream95 has quit [Ping timeout: 480 seconds]
MrCooper has joined #dri-devel
mclasen has joined #dri-devel
Daaanct12 has quit [Remote host closed the connection]
Lucretia has quit []
Lucretia has joined #dri-devel
devilhorns has joined #dri-devel
DottorLeo has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
<DottorLeo> hi!
<DottorLeo> i see there are 2MR about switching to Dynamic Rendering (ANV and RADV). I'm curious...what it means? I've tried to search online but i'm not sure about it. It's like the tecnique that PS4 and XBOX do?
<pendingchaos> I doesn't mean much for end users
<pendingchaos> it's a refactor that simplifies some code in the driver
<DottorLeo> oh thanks!
DottorLeo has quit [Quit: Leaving]
<technopoirot> MrCooper: thanks! I suspected glEGLImageTargetTexture2DOES too
<technopoirot> it does appear to only be called once from pixmap_from_buffers
<MrCooper> right; note that while fixing that should be straightforward in Xwayland, it's trickier in Xorg
<MrCooper> since there's no direct connection between the Present and glamor code there
<technopoirot> just as an experiment to see if I was on the right track, I modified glamor_copy_fbo_fbo_draw to cause the texture to be deleted (at the end of the function) and recreated (at the beginning) via glamor_pixmap_ensure_fbo
<technopoirot> the red rectangle appeared as usual then disappeared on the next copy_area, but was never repainted. does that make sense to you?
<technopoirot> I kind of also thought jekstrand was impliying I wouldn't need to call glEGLImageTargetTexture2DOES again
<technopoirot> that was the impetus of my original question re: updating the texture created by dri3_pixmap_from_buffers
Company has joined #dri-devel
preda has quit []
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
Guest860 has quit []
tobiasjakobi has joined #dri-devel
leah has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
cef is now known as Guest176
cef has joined #dri-devel
Guest176 has quit [Ping timeout: 480 seconds]
Peste_Bubonica has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
itoral has quit []
apinheiro has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
mclasen has joined #dri-devel
adjtm has quit [Read error: Connection reset by peer]
<danvet> agd5f, I pondered the rpm issue again some more
<danvet> do you have some guarantee that the device is always resumed when you do an ioctl?
<danvet> otherwise there's a deadlock with drm_modeset_lock -> rpm_resume -> stalling for rpm_suspend to finish -> drm_modeset_lock
<danvet> I think nouveau has some hacks to just blindly rpm resume the device around ioctl
<danvet> but that doesn't cover fbcon and it's kinda a hack
<danvet> I also wonder whether it's worth to kick gregkh/rafael wyzocki whether they thought about lockdep annotations to catch these
<danvet> since it's really easy to accidentally invert these and cause rpm deadlocks
<danvet> another classic is rpm suspend shooting down mmaps and mmap handler having to rpm resume
<danvet> that one does work, but only with extreme care
<javierm> danvet: btw, I moved stuff around in vesafb to match the order in which the resources are acquired in the driver (that may be wrong, but don't really wanted to touch more than needed)
<javierm> danvet: I could also not move more than framebuffer_release() if you prefer
<javierm> danvet: this also show how important are the drm helpers, since driver authors don't really need to care about these details like in fbdev
<javierm> fbdev seems to be one driver getting it wrong and all others carrying the same bugs due copy & paste
jewins has joined #dri-devel
<danvet> javierm, well also all of fbdev predates hotunplug support by a lot
<danvet> so no surprise it's wobbly at best
<danvet> Linus Torvalds has done most of the bugfixing around hotunplug races in the past few decades there
<MrCooper> technopoirot: doubtful that recreating the FBO would make a difference, glEGLImageTargetTexture2DOES makes sure the GL texture reflects the current contents of the EGLImage
hch12907 has joined #dri-devel
JohnnyonFlame has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
lemonzest has quit [Quit: WeeChat 3.4]
gawin has quit [Ping timeout: 480 seconds]
shashanks has joined #dri-devel
iive has joined #dri-devel
`join_subline has quit [Read error: Connection reset by peer]
`join_subline has joined #dri-devel
<anholt> jekstrand: are you running a current deqp-runner release? that sounds like the thing we fixed where new vk cts started doing statuses differently.
<anholt> but, also, please upload a log next time so I can actually do something about a report if it is a new issue.
<alyssa> anholt: relatedly, is Missing expected if every test in a section is skipped?
<anholt> no
<alyssa> crap! :p
* alyssa crawls back to her GLES hole
<anholt> missing is "we asked deqp to run some tests, and deqp didn't know what any of those tests were"
<anholt> usually it's you git checkouted and forgot to ninja your deqp.
ella-0 has joined #dri-devel
heat_ has joined #dri-devel
<agd5f> danvet, the driver wraps the ioctl call and makes sure the device is resumed before the IOCTL is run
<danvet> agd5f, hm yeah when you do it like that then it's much more a redo ...
Guest26 is now known as bluepenquin
lumag_ has quit [Ping timeout: 480 seconds]
sravn has quit [Quit: WeeChat 3.5]
maxzor has joined #dri-devel
<technopoirot> MrCooper: ok, I'm going to work on trying that, but what would explain it working on a different platform without an additional glEGLImageTargetTexture2DOES call?
Danct12 has quit [Remote host closed the connection]
sravn has joined #dri-devel
<lynxeye> technopoirot: Which GPU are you on?
tzimmermann has quit [Quit: Leaving]
<technopoirot> etnaviv :)
<technopoirot> lynxeye: ^^
<lynxeye> technopoirot: Which GPU core specifically (GC...). They differ massively in their level of braindeadness ;)
<technopoirot> lynxeye: GC400LT
<technopoirot> lynxeye: pretty sure this one has maximum braindeadness
<lynxeye> technopoirot: Hm, not sure about this on. Maybe you get supertiled render buffer and I'm pretty sure this one can't read supertiled, so you get a shadow copy for texturing.
MajorBiscuit has joined #dri-devel
<technopoirot> lynxeye: yes, that seems to match what I observe on the client side, but it's not clear to me how that connects to Xorg via dri3_copy_area
sdutt has quit [Ping timeout: 480 seconds]
<lynxeye> technopoirot: Other GPUs are mostly able to texture from their renderbuffer format, so they are much more forgiving in case your GL app violates the rules on when render content needs to be visible for texturing. Etnaviv on those GPus tend to be pretty strict about this to avoid useless copies between render and texture buffer.
hch12907 has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
jimjams has joined #dri-devel
<alyssa> any GPU that can't texture everything it can render is broken
<alyssa> lukewarm take
<karolherbst> :D
<karolherbst> alyssa: soo.. all GPUs?
<alyssa> I think Mali is fine here at least
<lynxeye> technopoirot: If glamor created the texture from the egl image via glEGLImageTargetTexture2DOES, then rebinding the texture should be enough to get the current context of the shared buffer into the texture shadow.
maxzor has quit [Ping timeout: 480 seconds]
<karolherbst> alyssa: although I think nvidia can also texture everthing
<technopoirot> lynxeye: ok, just trying to make sure I follow. it does look like I have linear formatted texture buffer, and a supertiled render buffer.
<karolherbst> being able to render but not texture feels weird
<technopoirot> lynxeye: are you saying the shared buffer is rendered in a format that then can't be textured onto the window?
<lynxeye> technopoirot: I don't think this GPU can texture from linear. So if you really have a linear buffer shared between client and server you would get something like supertiled render buffer -> blit to shared linear buffer on the client side. Then linear shared buffer -> blit to tiled texture buffer on the server side.
<lynxeye> The blit from linear to tiled texture is done on texture bind for OES external textures or only once when creating the texture for 2D textures.
<technopoirot> lynxeye: I see, so other platforms that can support texture from linear appear ok without the extra glEGLImageTargetTexture2DOES?
<technopoirot> or rather those platforms are just supertiled -> supertiled or something like that?
<anholt> tomeu: lava seems to have run out of space https://gitlab.freedesktop.org/mesa/mesa/-/jobs/22223235
<technopoirot> lynxeye: sorry for my naivety :)
<lynxeye> technopoirot: Some Vivante GPUs can texture from linear and some newer cores can also sample from supertiled. So yes, ideally you would just get direct sampling from the supertiled renderbuffer.
<MrCooper> lynxeye: when this was discussed here earlier, the consensus was that glEGLImageTargetTexture2DOES needs to be called again for this
<technopoirot> MrCooper: yes, I'm in the process of trying that, but wanted to make sure I understood why this was required for my platform. I think lynxeye has helped me confirm that.
<MrCooper> technopoirot: most platforms can just sample from the imported buffer directly, so repeated glEGLImageTargetTexture2DOES calls are redundant for them
<lynxeye> MrCooper: Nope. OES external spec says: "Binding (or re-binding if already bound) an external texture by calling BindTexture after all modifications are complete guarantees that sampling done in future draw calls will return values corresponding to the values in the buffer at or after the time that BindTexture is called."
<technopoirot> MrCooper: I made an initial attempt but didn't see anything rendered (not even the initial frame), but maybe I didn't have the right texture bound when I called glEGLImageTargetTexture2DOES again
stuart has joined #dri-devel
<MrCooper> lynxeye: and that's not specific to EXTERNAL_OES textures?
gpiccoli has quit [Quit: Bears...Beets...Battlestar Galactica]
<anholt> ajax: I wonder how many of the piglit swrast flakes will go away if we update to your new libx11
sdutt has joined #dri-devel
<MrCooper> lynxeye: glamor doesn't use EXTERNAL_OES
gpiccoli has joined #dri-devel
<technopoirot> lynxeye: are you suggesting I only need to glBindTexture? I think I had tried that but ran into the targetIndex != TEXTURE_EXTERNAL_INDEX condition in mesa's bind_texture_object, which pointed me to GL_OES_image_external
<technopoirot> MrCooper: is ^^ what you mean by glamor doesn't use EXTERNAL_OES?
nchery has joined #dri-devel
gpiccoli has quit []
<technopoirot> I can't remember what interface I traced that targetIndex flag to
<daniels> anholt: fixed
<anholt> thanks!
<daniels> no
<daniels> *np
<daniels> I sure do love the way Docker randomly changes everything exposed in its API all the time
<MrCooper> technopoirot: I suspect the spec language quoted by lynxeye is specific to EXTERNAL_OES textures, which glamor doesn't use, therefore it needs to call glEGLImageTargetTexture2DOES again
<anholt> daniels: uh oh. do I need to worry about docker gcing on my runners too?
<lynxeye> MrCooper: It is. Got me confused by the function name :/
<daniels> anholt: as long as it's not complaining about 'Invalid isoformat string'
<lynxeye> Regular 2D textures require recreating the texture from the egl image to pull in content changes.
MajorBiscuit has quit [Quit: WeeChat 3.4]
<daniels> anholt: that machine is set to BST rather than UTC, so it looks like docker writes out 2022-01-01T12:34:56 during normal time, and 2022-06-01T12:34:56+01:00 during summer time
<daniels> which rather confounds the bit where we append +00:00 to make it acceptable to Python's datetime
<anholt> everything is awful, you say?
gpiccoli has joined #dri-devel
<technopoirot> lynxeye: MrCooper: thank you, you have been super helpful. gotta break for lunch, but I'll try the glEGLImageTargetTexture2DOES again and report back
gpiccoli has quit [Quit: Bears...Beets...Battlestar Galactica]
i-garrison has quit [Read error: Connection reset by peer]
i-garrison has joined #dri-devel
MajorBiscuit has joined #dri-devel
jbarnes has quit [Read error: Connection reset by peer]
jbarnes has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
<Venemo> when using blame on the mesa gitlab, is it possible to make it ignore whitespace only changes?
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
gpiccoli has joined #dri-devel
tobiasjakobi has quit []
<daniels> anholt: are you ok giving gallo direct access? https://gitlab.freedesktop.org/mesa/mesa/-/issues/5935
<MrCooper> Venemo: git blame -w ?
<Venemo> MrCooper: how do I make gitlab work like that?
<MrCooper> no idea
<karolherbst> try passing -w in the URL after the commit and hope gitlab does a bad job sanitizing inputs?
<gawin> I think it would look "?w=1"
<daniels> karolherbst: it's a long long long way from system("git blame $url")
<karolherbst> daniels: one can still hope
FireBurnUK has joined #dri-devel
FireBurn has quit [Read error: Connection reset by peer]
dj-death_ has joined #dri-devel
dj-death has quit [Ping timeout: 480 seconds]
devilhorns has quit []
sdutt has quit [Ping timeout: 480 seconds]
<alyssa> think of the CI, vote against daylight savings!
stuart has quit [Remote host closed the connection]
stuart has joined #dri-devel
jimjams has quit [Quit: Connection closed for inactivity]
<zmike> dcbaker: going to do a few more backports
<anholt> zmike: got some folks looking at zink-on-venus. you would agree that vk_CreateBuffer should be basically free, right?
sdutt has joined #dri-devel
<zmike> yeah probably
<dcbaker> zmike: you broke the staging/22.1 branch
<zmike> oh no
<zmike> hahah
<zmike> what's broken?
<dcbaker> the build
<zmike> what
<zmike> I just built it though
<dcbaker> dirty working tree?
<zmike> 🤔
<dcbaker> fails to build locally for me too
<zmike> hold on a sec...
<zmike> okay what about now
* zmike has a hard time keeping track of all the patches
karolherbst has quit [Quit: Konversation terminated!]
thellstrom has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.4]
alyssa has left #dri-devel [#dri-devel]
<dcbaker> seems fixed
<dcbaker> thanks
<zmike> 👍
<dcbaker> I've added a couple patches on top of that, in case you need to force push
<zmike> cool
karolherbst has joined #dri-devel
dj-death_ has left #dri-devel [#dri-devel]
dj-death has joined #dri-devel
nchery has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
<karolherbst> mhh, I am wondering if we should return a struct from create_compute_state instead of void*, which can store informations about the shaders generated, which we'll need in OpenCL
<karolherbst> like "max threads allowed"
<karolherbst> let's see what we need
<karolherbst> max global size.. yeah.. that might be required with nv50
<karolherbst> threads per block, okay
Peste_Bubonica has quit [Remote host closed the connection]
<karolherbst> prefered threads multiple (I guess iris could report 8/16/32 there based on the simd size?)
Peste_Bubonica has joined #dri-devel
<karolherbst> ohh not global mem size, but global size.. ahh
<karolherbst> so threads * blocks
<karolherbst> ehh.. has to return an error for non custom devices
<karolherbst> nvm then
<karolherbst> so max threads per blocks is what we need to know
mszyprow_ has joined #dri-devel
<karolherbst> ahhhh
<karolherbst> I hate auto magic tools
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<technopoirot> lynxeye: MrCooper: zomg it worked!!1!
nchery has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
stuart has quit [Remote host closed the connection]
urja has quit [Ping timeout: 480 seconds]
mszyprow_ has quit [Ping timeout: 480 seconds]
<gpiccoli> Hi folks, quick question: though I checked the (great) DRM documentation, couldn't find the meaning of CRTC, I mean..is it an acronym I imagine? Sorry if it's a silly question or if it is documented and I miss it =)
<marex> cathode ray tube controller , no ?
<HdkR> I'd guess quite a few people these days would then ask, "What's a cathode ray tube for?"
jkrzyszt has quit [Remote host closed the connection]
<karolherbst> What's a cathode ray tube for?
<ajax> for going cathode ray tubing, of course
<karolherbst> ahh, is that like ray tracing v2?
adjtm has joined #dri-devel
<karolherbst> always excited about new stuff
<HdkR> ray tracing v2 should include driver provided GL_POLYGON intersection testing
<gpiccoli> cool, thanks marex hehe
<gpiccoli> found it in one single place in the whole kernel, Documentation/gpu/amdgpu/display/dc-glossary.rst heheh
gawin has quit [Ping timeout: 480 seconds]
<gpiccoli> (I could have searched for glossary, silly me!)
<Lyude> i didn't even know we had a glossary
mclasen has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
reductum has quit [Quit: WeeChat 2.8]
reductum has joined #dri-devel
urja has joined #dri-devel
jimjams has joined #dri-devel
mclasen has joined #dri-devel
Haaninjo has quit [reticulum.oftc.net coulomb.oftc.net]
adjtm has quit [reticulum.oftc.net coulomb.oftc.net]
dj-death has quit [reticulum.oftc.net coulomb.oftc.net]
karolherbst has quit [reticulum.oftc.net coulomb.oftc.net]
FireBurnUK has quit [reticulum.oftc.net coulomb.oftc.net]
gpiccoli has quit [reticulum.oftc.net coulomb.oftc.net]
ppascher has quit [reticulum.oftc.net coulomb.oftc.net]
tursulin has quit [reticulum.oftc.net coulomb.oftc.net]
danvet has quit [reticulum.oftc.net coulomb.oftc.net]
Duke`` has quit [reticulum.oftc.net coulomb.oftc.net]
CATS has quit [reticulum.oftc.net coulomb.oftc.net]
shadeslayer has quit [reticulum.oftc.net coulomb.oftc.net]
neonking_ has quit [reticulum.oftc.net coulomb.oftc.net]
Strit[m] has quit [reticulum.oftc.net coulomb.oftc.net]
robertmader[m] has quit [reticulum.oftc.net coulomb.oftc.net]
Vin[m] has quit [reticulum.oftc.net coulomb.oftc.net]
moben[m] has quit [reticulum.oftc.net coulomb.oftc.net]
hasebastian[m] has quit [reticulum.oftc.net coulomb.oftc.net]
x512[m] has quit [reticulum.oftc.net coulomb.oftc.net]
mighty17 has quit [reticulum.oftc.net coulomb.oftc.net]
go4godvin has quit [reticulum.oftc.net coulomb.oftc.net]
PiGLDN[m] has quit [reticulum.oftc.net coulomb.oftc.net]
dcbaker has quit [reticulum.oftc.net coulomb.oftc.net]
arisu has quit [reticulum.oftc.net coulomb.oftc.net]
tintou has quit [reticulum.oftc.net coulomb.oftc.net]
cleverca22[m] has quit [reticulum.oftc.net coulomb.oftc.net]
exit70[m] has quit [reticulum.oftc.net coulomb.oftc.net]
Mershl[m] has quit [reticulum.oftc.net coulomb.oftc.net]
zzoon_holidays_till_8th[m] has quit [reticulum.oftc.net coulomb.oftc.net]
gdevi has quit [reticulum.oftc.net coulomb.oftc.net]
Anson[m] has quit [reticulum.oftc.net coulomb.oftc.net]
RAOF has quit [reticulum.oftc.net coulomb.oftc.net]
nielsdg has quit [reticulum.oftc.net coulomb.oftc.net]
glennk has quit [reticulum.oftc.net coulomb.oftc.net]
mal has quit [reticulum.oftc.net coulomb.oftc.net]
mwk has quit [reticulum.oftc.net coulomb.oftc.net]
leandrohrb has quit [reticulum.oftc.net coulomb.oftc.net]
evadot has quit [reticulum.oftc.net coulomb.oftc.net]
macc24 has quit [reticulum.oftc.net coulomb.oftc.net]
mlankhorst has quit [reticulum.oftc.net coulomb.oftc.net]
swick has quit [reticulum.oftc.net coulomb.oftc.net]
egbert has quit [reticulum.oftc.net coulomb.oftc.net]
pepp has quit [reticulum.oftc.net coulomb.oftc.net]
ickle has quit [reticulum.oftc.net coulomb.oftc.net]
mupuf has quit [reticulum.oftc.net coulomb.oftc.net]
BobBeck has quit [reticulum.oftc.net coulomb.oftc.net]
rawoul has quit [reticulum.oftc.net coulomb.oftc.net]
padovan has quit [reticulum.oftc.net coulomb.oftc.net]
jkqxz has quit [reticulum.oftc.net coulomb.oftc.net]
CounterPillow has quit [reticulum.oftc.net coulomb.oftc.net]
mriesch has quit [reticulum.oftc.net coulomb.oftc.net]
pH5 has quit [reticulum.oftc.net coulomb.oftc.net]
LaserEyess has quit [reticulum.oftc.net coulomb.oftc.net]
HdkR has quit [reticulum.oftc.net coulomb.oftc.net]
tomeu has quit [reticulum.oftc.net coulomb.oftc.net]
Stary has quit [reticulum.oftc.net coulomb.oftc.net]
jannau has quit [reticulum.oftc.net coulomb.oftc.net]
Venemo has quit [reticulum.oftc.net coulomb.oftc.net]
mmind00 has quit [reticulum.oftc.net coulomb.oftc.net]
V has quit [reticulum.oftc.net coulomb.oftc.net]
q66 has quit [reticulum.oftc.net coulomb.oftc.net]
Plagman has quit [reticulum.oftc.net coulomb.oftc.net]
tagr has quit [reticulum.oftc.net coulomb.oftc.net]
gruetze_ has quit [reticulum.oftc.net coulomb.oftc.net]
jcristau has quit [reticulum.oftc.net coulomb.oftc.net]
kbingham has quit [reticulum.oftc.net coulomb.oftc.net]
haagch has quit [reticulum.oftc.net coulomb.oftc.net]
kbingham has joined #dri-devel
adjtm has joined #dri-devel
dj-death has joined #dri-devel
FireBurnUK has joined #dri-devel
karolherbst has joined #dri-devel
gpiccoli has joined #dri-devel
danvet has joined #dri-devel
Duke`` has joined #dri-devel
ppascher has joined #dri-devel
CATS has joined #dri-devel
neonking_ has joined #dri-devel
x512[m] has joined #dri-devel
shadeslayer has joined #dri-devel
tintou has joined #dri-devel
Strit[m] has joined #dri-devel
tursulin has joined #dri-devel
robertmader[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
Haaninjo has joined #dri-devel
nielsdg has joined #dri-devel
Vin[m] has joined #dri-devel
moben[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
zzoon_holidays_till_8th[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
gdevi has joined #dri-devel
exit70[m] has joined #dri-devel
Anson[m] has joined #dri-devel
dcbaker has joined #dri-devel
cleverca22[m] has joined #dri-devel
RAOF has joined #dri-devel
arisu has joined #dri-devel
tagr has joined #dri-devel
mal has joined #dri-devel
mighty17 has joined #dri-devel
glennk has joined #dri-devel
mwk has joined #dri-devel
gruetze_ has joined #dri-devel
pH5 has joined #dri-devel
haagch has joined #dri-devel
leandrohrb has joined #dri-devel
q66 has joined #dri-devel
V has joined #dri-devel
mlankhorst has joined #dri-devel
BobBeck has joined #dri-devel
tomeu has joined #dri-devel
padovan has joined #dri-devel
mriesch has joined #dri-devel
Stary has joined #dri-devel
LaserEyess has joined #dri-devel
macc24 has joined #dri-devel
Plagman has joined #dri-devel
jannau has joined #dri-devel
HdkR has joined #dri-devel
egbert has joined #dri-devel
jkqxz has joined #dri-devel
mupuf has joined #dri-devel
evadot has joined #dri-devel
Venemo has joined #dri-devel
swick has joined #dri-devel
CounterPillow has joined #dri-devel
mmind00 has joined #dri-devel
ickle has joined #dri-devel
jcristau has joined #dri-devel
rawoul has joined #dri-devel
pepp has joined #dri-devel
mvlad has quit [Remote host closed the connection]
swick has quit [Ping timeout: 484 seconds]
go4godvin has joined #dri-devel
<marex> karolherbst: more like raytracing v0
Danct12 has joined #dri-devel
<marex> CRT raytraced before raytracing was cool, heh
go4godvin is now known as Guest205
<karolherbst> analog ray tracing
<marex> heh
swick has joined #dri-devel
dj-death has quit [Quit: leaving]
dj-death has joined #dri-devel
rkanwal has quit [Quit: rkanwal]
rasterman- has joined #dri-devel
Peuc has quit [Quit: Peuc]
rasterman- has quit []
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
Danct12 has quit [Quit: Quitting]
nchery has joined #dri-devel
Danct12 has joined #dri-devel
cef has quit [Quit: Zoom!]
Peuc has joined #dri-devel
nchery is now known as Guest208
nchery has joined #dri-devel
Guest208 has quit [Ping timeout: 480 seconds]
adjtm has quit [Quit: Leaving]
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
apinheiro has joined #dri-devel
maxzor has joined #dri-devel
mszyprow_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
icecream95 has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<jimjams> Hi! I'm pretty new to kernel dev, but am eager to help out with some work on VKMS. I have the first patch of a series that gets ConfigFS for VKMS wired up, and I'd like to see if I'm on the right track. Is the best way to get some early feedback on it to send an RFC patch to the dri-devel list?
alatiera has joined #dri-devel
<alatiera> rolling out a new windows runner on gitlab, if there are any weird issues feel free to ping me
<alatiera> the new runner is server2022, and it can run any container version with hyper-v as well
<javierm> jimjams: yes, and Cc'ing the VKMS maintainers (./scripts/get_maintainer.pl -f drivers/gpu/drm/vkms/)
frankbinns has quit [Quit: Leaving]
<alatiera> (nevermind the hyper-v part, gitlab-runner can't make use of it)
<jimjams> Easy enough! Thanks
mszyprow_ has quit [Ping timeout: 480 seconds]
stuart has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
Lucretia has quit []
tursulin has quit [Read error: Connection reset by peer]
<karolherbst> anholt: CI doesn't want your change as it seems :(
<anholt> iris CI is thoroughly neglected
<anholt> lava lab was down this morning. bcm lab was down last night.
<karolherbst> ahh :(
<anholt> and there's also fallout from the lava runner scripts rework
<karolherbst> yeah.. it takes people to care, but I assumed that intel would do that work?
rasterman has quit [Quit: Gettin' stinky!]
<anholt> they've got their private lab and don't work on the upstream ci.
<karolherbst> ahh :(
nchery has quit [Ping timeout: 480 seconds]
mclasen has quit []
apinheiro has quit [Quit: Leaving]
nchery has joined #dri-devel
pcercuei has quit [Quit: dodo]
<karolherbst> pro tolls of hell: 300 frigging threads
<karolherbst> *tools
<karolherbst> fun
Haaninjo has quit [Quit: Ex-Chat]
<karolherbst> we hit a bug in the pro tool, which apparently tries to claim the alsa device *facepalm*
iive has quit []
<karolherbst> noooo
Peste_Bubonica has quit [Quit: Leaving]
sdutt has quit [Remote host closed the connection]