ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pnowack has quit [Quit: pnowack]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.3]
rasterman has quit [Quit: Gettin' stinky!]
ybogdano has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
khfeng has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
X-Scale has joined #dri-devel
X-Scale` has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
JonasTripps has joined #dri-devel
JonasTripps has left #dri-devel [#dri-devel]
K`den has joined #dri-devel
Kayden has quit [Read error: Connection reset by peer]
K`den is now known as Kayden
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]
<imirkin>
whoa. fun tidbit in ES 3.1: "Except for image variables qualified with the format qualifiers r32f, r32i, and r32ui, image variables must specify either memory qualifier readonly or the memory qualifier writeonly."
<imirkin>
i did not know that.
<imirkin>
and that's the story of how Adreno A4xx gets away with putting images through the texture cache
<imirkin>
it does an "buffer-type" load for the 32-bit formats
<imirkin>
and everything else can't be written.
<imirkin>
sneaky.
<imirkin>
[and obviously desktop GL has no such restrictions. i wouldn't be surprised if it were also gone in ES 3.2, but i haven't checked)
ngcortes has quit [Remote host closed the connection]
<imirkin>
is there a pre-existing pass to lower image loads from "bytes" to typed values?
<imirkin>
i know at least intel uses something like that
<imirkin>
(and nouveau does too, but it's in the backend lowering logic)
<imirkin>
i'm looking for a "off the shelf" pass, ideally
<imirkin>
aha, looks like src/intel/compiler/brw_nir_lower_storage_image.c has something, but it's non-generic
<imirkin>
oh, i see there are nir_format helpers. those could be helpful.
<anholt_>
v3d_nir_lower_image_load_store may help
<anholt_>
also, that was news to me with readonly/writeonly.
Company has quit [Read error: No route to host]
<imirkin>
no such thing on desktop
<imirkin>
but ... it's ES hw
<anholt_>
yeah
<imirkin>
i'm writing a comment in your image coherency bug
Company has joined #dri-devel
<imirkin>
anholt_: yeah, v3d_nir_lower_image_load looks precisely like what i wanted. except there's no way it works ... it doesn't handle 8-bit int formats at least
<imirkin>
or there's something more going on than meets the eye
<anholt_>
oh. I don't think it's going to be useful for you for image loads, actually. I think the image loads are getting format conversion by the texture unit, and you just have to massage the 16-bit values for small internal formats into 32-bit nir values.
<imirkin>
ah i see
<anholt_>
so it's just the stores that do the "pack up some dwords to store"
<imirkin>
that makes more sense then
<imirkin>
yeah, this is the opposite. image loads are just coming back as memory
<anholt_>
yeah. had paged this all out except for "I know I wrote some"
<imirkin>
(but since they restrict to single-component 32-bit, it all works out)
<imirkin>
at least a4xx looks to be in that generation where typed image loads aren't a thing.
<imirkin>
nvidia had some of those. i think intel did too.
<anholt_>
worst is that intermediate generation where you have to roll your own addressing math for images
* anholt_
just never did it for v3d 3.x
<imirkin>
anholt_: i wrote logic to recalculate tiling on nv50 and nvc0
<imirkin>
to go from 3d tiling to 2d
<imirkin>
because the image unit only knows about 2d :)
<anholt_>
my worst tiling logic was vc4 where the texture unit could only sample tiled but I had to address raster images.
<imirkin>
(could have just z-untiled textures first, but that felt dirty. plus non-trivial)
<anholt_>
every once in a while I have to reread that code and start by declaring that it's clearly all wrong.
<imirkin>
i only sorted it out through a python-based simulator
<imirkin>
so many different params
<anholt_>
for a6xx 3d textures I was starting to muse about whether I could plug layouts into wolfram somehow and have it tell me what the right layout function was.
<imirkin>
lol
slattann has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
mclasen has quit [Remote host closed the connection]
mclasen has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
<imirkin>
anholt_: btw, sure enough, we enforce that restriction in mesa as well (ast_to_hir.cpp::apply_image_qualifier_to_variable)
<anholt_>
I really wonder what hardware would want the coherent flag at all
<imirkin>
on nvidia, iirc it makes us go to L2 directly
<imirkin>
I believe V = volatile, G = global, A = all
<imirkin>
in reference to which caches are written/read
<anholt_>
but the CA mode does still give you the right behavior within an invocation?
<imirkin>
sure
<imirkin>
that makes it hit L1, which is more "local"
<imirkin>
like if you have a compute shader with a width of 1024
<imirkin>
it'll still run them 32-wide per "processor"
<imirkin>
but there can be multiple such processors
<imirkin>
depending on the GPU
<imirkin>
(i always get confused by the terminology... there's SM, but there are also smaller things)
<HdkR>
Pipelines, SM, TPC, GPC? :P
<imirkin>
yeah. they all fit into each other in some order.
<imirkin>
i guess the order you listed ;)
<HdkR>
You also need to deal with cross-device atomics of course
camus has joined #dri-devel
<imirkin>
i barely deal with in-invocation atomics
<imirkin>
you're supposed to various flush caches after them
<imirkin>
if you plan on re-reading the same spot
<imirkin>
since i think the atomic only affects the L2 cache, but if you have stale data in L1, then ... sad.
<imirkin>
this is why tgsi has a "atomic" annotation on a whole buffer
<imirkin>
coz then i just make everything volatile on those
<imirkin>
used for atomic counter buffers
Duke`` has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Company has quit [Read error: Connection reset by peer]
Walt has joined #dri-devel
<Walt>
a
<Walt>
What is a fallium frontend?
<HdkR>
A misspelling of gallium frontend
<Walt>
exactly
<Walt>
What is a gallium frontend?
zf has quit [Ping timeout: 480 seconds]
<HdkR>
Gallium is an API that mesa provides to the drivers for abstracting away a bunch of OpenGL details
<imirkin>
other way around
<imirkin>
drivers provide a gallium API for a mesa frontend to implement a "real" API with (e.g. OpenGL, OpenCL, etc)
<imirkin>
a mesa frontend's job is to make up for the impedance mismatch between whatever API you want and gallium
shashank_sharma has quit [Remote host closed the connection]
<Walt>
I was reading the nine frontend and it seems that it was implementing dx9 yet it was importing d3d9.h as a header which was outside of the /frontend/nine directory
<Walt>
Does it just implement the target API using the gallium API(which is what I think you are saying)
<Walt>
Or is something happening that I do not understand(this is what probably is happening :p)
<imirkin>
nope. it just implements the d3d9 API (well, most of it)
<Walt>
Can apps call the API with #import<nine/header..h>?
<imirkin>
something like that. have a look at Xnine
<imirkin>
that's an example of a non-wine thing which uses libd3d9adapter
<Walt>
Oh, so I wont call nine independently by doing something like #include <d3d9.h>
<imirkin>
it's all in that project.
lemonzest has joined #dri-devel
<imirkin>
look at its includes dir, for example.
<Walt>
by the include dir you mean /include/foo?
<imirkin>
i mean look through that whole project and understand it
<imirkin>
that should explain to you how one can use the thing provided by nine.
<Walt>
Ok, I will lokk though it more thouroughly right now! thx
zf has joined #dri-devel
<jenatali>
imirkin: Re: image loads, D3D only recently (2015, D3D11/12) started supporting loads from formats other than the 32bpp formats. Pretty sure that just wasn't a hardware thing until around then
vivijim has quit [Remote host closed the connection]
<imirkin>
jenatali: D3D10 didn't support images at all, so D3D11 would have been the first opportunity for it :)
zf` has joined #dri-devel
<imirkin>
jenatali: anyways, Fermi / Kepler only supported un-formatted loads. the driver then just did the conversion in the shader.
<jenatali>
True. Still, 5 years after D3D11's initial release
<imirkin>
starting Maxwell, it can do formatted image loads
<imirkin>
and yeah, i think Maxwell was like 2015/16, so that lines up
<imirkin>
curiously this hardware somehow manages to still fail even with 32-bit formats with multiple components
<imirkin>
i need to do some debugging to see what's up
<imirkin>
what'd be helpful would be if you could tell me how this particular hw works
<imirkin>
but ... i doubt Adreno A400-series is much on your radar
zf`_ has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
zf has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
zf` has quit [Ping timeout: 480 seconds]
<jenatali>
Yeah I honestly couldn't tell you which hardware that maps to, other than a rough timeframe of the hardware that D3D supported in ~2015
itoral has joined #dri-devel
<imirkin>
;)
mattrope has quit [Read error: Connection reset by peer]
<imirkin>
ultimately the driver has to support whatever APIs irrespective of the hardware's capabilities
<imirkin>
so here's it's just a matter of properly understanding what the various instructions do, their limitations, etc
slattann has quit []
oakk has quit [Remote host closed the connection]
oakk has joined #dri-devel
slattann has joined #dri-devel
danvet has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
pnowack has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
garrison has quit []
i-garrison has joined #dri-devel
i-garrison has quit []
jkrzyszt_ has joined #dri-devel
i-garrison has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
slattann has quit []
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<danvet>
mripard, did you not push drm-misc-fixes to -rc1?
<danvet>
daniels, in general to dma-buf import extensions own the fd reference and close that, or apps?
<mripard>
danvet: no, dim didn't let me since drm-fixes wasn't in tip
<danvet>
mripard, oh
<danvet>
mripard, I didn't know
<danvet>
mripard, can you just force it since sorting out the -rc1 mess will take a bit of time
<mripard>
yeah, I didn't either :)
<mripard>
sure, on it
<danvet>
mripard, and ping könig so he can cherry-pick the fixes
itoral has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
<mripard>
the merge is done, I'm compiling and will push if it works (so in like ~20 minutes)
gpuman has joined #dri-devel
Luc has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
<mripard>
danvet: done
tursulin has joined #dri-devel
rasterman has joined #dri-devel
tzimmermann has joined #dri-devel
linearcannon has quit [Read error: No route to host]
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
Luc has quit [Remote host closed the connection]
<danvet>
Lyude, did you delete a bunch of topic branches without using dim?
<danvet>
or jani ?
<danvet>
dim rebuild-tip is now busted
<danvet>
and since the remote is gone, I also now cannot use dim remove-branch
<jani>
danvet: argh, I removed one using dim remove-branch
<danvet>
jani, oh did it not push out because rebuild-tip was busted?
<jani>
danvet: I wonder if we ended up in some broken state because drm-tip rebuild failed with the conflicts after that
<jani>
right
<danvet>
yeah probably
<danvet>
I'll delete it manually
<danvet>
why is -rc1 always this much fun :-/
<jani>
this is the one I removed: topic/drm-dp-training-delay-helpers
<jani>
nothing else
<danvet>
yeah that's the one that goes boom because it's not there yet
<danvet>
the --ff-only fails
<danvet>
but then also the git commit fails
<danvet>
and the script just dies
<jani>
ugh
<danvet>
ok it seems to have worked now
<jani>
good, thanks
<danvet>
I'll type some error handling for next time around
<javierm>
danvet, tzimmermann: hi, I would like to know your opinion on what Geert mentioned in the patch that prevents {efi,simple}fb to be probed if there's an fbdev registered already
camus has joined #dri-devel
<tzimmermann>
javierm, hi! do you a link?
<tzimmermann>
oh, just saw it
camus1 has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I was looking at the fbdev core and thought that maybe a cleaner option could be to make do_remove_conflicting_framebuffers() to just fail if struct fb_info .flags & FBINFO_MISC_FIRMWARE
<tzimmermann>
you both have a point :)
<javierm>
since there shouldn't be a case where it would be desirable to remove conflicting framebuffers for firmware setup framebuffer
<tzimmermann>
javierm, i'd just test if the aperture has been taken already and stop efifb if so
<tzimmermann>
but i'm not sure if all drivers register their framebuffer apertures correctly
<javierm>
tzimmermann: do we have a symbol exported for that in drivers/video/fbdev/core/fbmem.c already?
<tzimmermann>
at least in DRM land, that's not the case
<tzimmermann>
there's no such test AFAIK
<javierm>
tzimmermann: another thing I noticed is that simpledrm doesn't mark their fb emulation as FBINFO_MISC_FIRMWARE
<javierm>
dunno if that's important or not
<tzimmermann>
noone builds HW-graphic drivers into the kernel. now they all come and suddenly want that feature
<tzimmermann>
for simpledrm it's not relevant
<tzimmermann>
the FIRMWARE flag is only used for aperture management in fbdev. and drm has it's own interfaces
<javierm>
tzimmermann: right
<javierm>
tzimmermann: so there's a apertures_overlap() that I could export for fbdev drivers to use. But I really wonder if is worth to have a bigger patch for this
<tzimmermann>
what was the original problem? someone built a kernel with simplefb and native support built in? why don't they just build the native driver as a module OR leave out simplefb? that's how it's been done for 20 yrs
<tzimmermann>
what i mean is, do we really want to solve this problem in the drivers?
pcercuei has joined #dri-devel
<javierm>
tzimmermann: correct, the problem was that both {efi,simple}fb and the DRM driver were built-in. And the latter probes first
<tzimmermann>
it seems like a lot of churn and heuristics for little gain
<javierm>
tzimmermann: agreed. I'm happy to just say DRM drivers should really be built as a module
<javierm>
as I caused this regression by moving the device registering to drivers/firmware, I wanted to fix the issue
<javierm>
but I can also re-spin the patch checking if the aperture range overlaps
<javierm>
tzimmermann: but answering your question, it either probed both DRM + efifb or DRM + simplefb, depending if CONFIG_SYSFB_SIMPLEFB=y was set or not
sneil has quit [Ping timeout: 480 seconds]
imre is now known as Guest6022
imre has joined #dri-devel
itoral has quit [Remote host closed the connection]
Guest6022 has quit []
itoral has joined #dri-devel
mclasen has joined #dri-devel
flacks has quit [Quit: Quitter]
Lucretia-backup has quit []
flacks has joined #dri-devel
Lucretia has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
tursulin has quit [Quit: Konversation terminated!]
nchery has joined #dri-devel
<javierm>
tzimmermann: it seems that having a fb_aperture_registered() helper is not trivial because for PCI devices is needed to translate PCI memory bars to aperture ranges
<javierm>
so it will require some refactoing in fbdev core to add that helper
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
itoral has quit [Remote host closed the connection]
X-Scale` has joined #dri-devel
<tzimmermann>
javierm, is there a memory mapping involved in that translation?
X-Scale has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I don't think so, remove_conflicting_pci_framebuffers() just does ap->ranges[idx].base = pci_resource_start(pdev, bar); and the same for .size
<javierm>
tzimmermann: I also wonder why do_register_framebuffer() doesn't attempt to remove_conflicting_pci_framebuffers()
<tzimmermann>
javierm, it's two different things
<daniels>
danvet: the FD is still the property of the app; if the API needs to keep the FD internally then it has to dup()
<danvet>
daniels, ah right
<karolherbst>
danvet: ohh.. before I forgot to mention this again. We might want to discuss upstreaming the CI files we use. I think you or airlied mentioned that we should discuss this upstream on lkml or so?
<daniels>
danvet: that's consistent across EGL, Vulkan, Wayland, etc
<danvet>
daniels, it was very early when I asked and way pre-coffee
slattann has quit []
<daniels>
:D
<daniels>
in fairness, EGL did originally specify the wrong thing, but it was so violently wrong that the spec got edited post-facto to flip behaviour
<javierm>
tzimmermann: and the kernel log says "checking generic (0 0) vs hw (c0000000 1d5000)"
<javierm>
that comes from fb_do_apertures_overlap(), thought the problem was the missing the PCI bar -> aperture translation to match
<tzimmermann>
javierm, virtio is a drm driver
<tzimmermann>
it doesn't use the fbdev code
<tzimmermann>
if any
pcercuei_ has joined #dri-devel
<tzimmermann>
most drm drivers don't reserve apertures
<tzimmermann>
only simpledrm does
<tzimmermann>
the other drivers only unplug simpledrm if necessary
<tzimmermann>
and none of them uses the fbdev infrastructure
<tzimmermann>
you cannot really solve the problem without intrusive changes to the aperture mgmt code AFAICT
pcercuei has quit [Ping timeout: 480 seconds]
<tzimmermann>
that's why i said that the problem might not be worth solving
<javierm>
tzimmermann: yes, but it does register an fbdev if DRM_FBDEV_EMULATION=y right ?
<tzimmermann>
javierm, probably. but that fbdev has nothing to do with PCI apertures
<javierm>
tzimmermann: ah, I see
<tzimmermann>
it uses a GEM buffer object, which is possibly relocatable
JohnnyonFlame has joined #dri-devel
<javierm>
tzimmermann: then it's even harder to have a check if the aperture ranges overlap, since it will only work for two fbdev drivers
<tzimmermann>
and in many cases, the buffer that fbdev sees is actually a shadow buffer in system ram
<javierm>
tzimmermann: got it
mclasen has quit []
<javierm>
then I don't know how we can use something better than num_registered_fb > 0 as condition to preven the {efi,simple}fb drivers to probe
mclasen has joined #dri-devel
<tzimmermann>
javierm, if the original approach works (testing for num_registered_fb) you shoudl take it. probing overlapping memory would be best, but it's probably unfeasible. sorry if i was imprecise about that
<tzimmermann>
num_registered_fb is still a hack with non-working corner cases.
<tzimmermann>
such as CONFIG_DRM_FBDEV_EMULATION == n
<javierm>
tzimmermann: agreed, num_registered_fb is still a hack. But my point was that the whole {efi,simple}fb is and I don't think that patch makes it more fragile
<tzimmermann>
true
<javierm>
tzimmermann: for simpledrm and native DRM we should have a cleaner way, danvet suggested to unregister the "simple-framebuffer" and "efi-framebuffer" platform devices
<tzimmermann>
for simpledrm, we can hot-unplug these devices before the driver binds, i think
<tzimmermann>
or unregister
mclasen has quit []
mclasen has joined #dri-devel
<javierm>
tzimmermann: yes, I will explore that but first wanted to fix the fbdev case since that's what was reported
<tzimmermann>
i don't know enougth about the driver model to know the best way
<javierm>
tzimmermann: thanks for the clarifications. Then I think that we should just go with the num_registered_fb > 0 workaround, it's not common anyways to have DRM drivers built-in
<tzimmermann>
javierm, but keep in mind that soner or later, there could be multiple devices that are served by simpledrm.
<tzimmermann>
unpluging the right one could be a problem ;)
<tzimmermann>
i don't have a good solution
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: interesting case. But even if there are multiple devices served by simpledrm, these would have different aperture ranges right?
<javierm>
so we could just do a drm_aperture_detach_drivers(base, size) ?
Company has joined #dri-devel
<tzimmermann>
javierm, yes, but not *before* these drivers have probed successfully
<javierm>
tzimmermann: scratch that, we are talking *before* the driver probes... so we have to unregister the device
<kisak>
it should be noted that there's nothing wrong with the actual plaintext commit message, gitlab just decided it needed to link to g.fd.o/Mesa_CI/repos/ because reasons
mclasen has quit []
mclasen has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
mclasen has quit []
mclasen has joined #dri-devel
<daniels>
kisak: because he pushed it to Mesa_CI/repos/ before he pushed it to kwg/mesa or mesa/mesa
<daniels>
aiui if it's available in the same repo then it links to that, and if not then it links to the first place it was seen
khfeng has quit [Ping timeout: 480 seconds]
<kisak>
Thanks, makes sense. Every time I want to jump through those links, I want mesa/mesa so that I can expand the tags to see if release branches have the commit.
tursulin has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
sneil has joined #dri-devel
tursulin has quit [Quit: Konversation terminated!]
<MrCooper>
kisak: bare commit hash references different project → referenced commit doesn't exist in this project → can't be on a release branch :)
<daniels>
MrCooper: just if you knew any more about how radeonsi dealt with modifiers; from a quick look it seemed like the change (making width0 && height0 != 0 for aux planes) should be harmless, but you might be aware of any lurking dragons
<daniels>
and I know you're a DRIImage enthusiast
<MrCooper>
bnieuwenhuizen added modifier support to radeonsi, I'm not that familiar with it
<daniels>
bnieuwenhuizen: I couldn't see any issue with that when I looked, but tmpl (with width0 and height0) is stashed away in the prsc so I wasn't sure if there were any if (width0 > 0) { /* not an aux plane */ } tests somewhere I didn't see
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
jewins has joined #dri-devel
<bnieuwenhuizen>
daniels: shouldn't have any. The check is plane id >= planes according to format
<daniels>
bnieuwenhuizen: right, resource_from_handle() itself looked fine, was just wondering if there were others, but awesome if there aren't
<daniels>
zmike: ^ sounds like an A-b
<zmike>
does sound like that
mattst88 has quit [Remote host closed the connection]
mattst88 has joined #dri-devel
Duke`` has joined #dri-devel
mbrost has joined #dri-devel
slattann has joined #dri-devel
<danvet>
Lyude, [PATCH] gpu/drm: fix potential memleak in error branch <- can you take a look at that one?
tzimmermann has quit [Quit: Leaving]
rgallaispou has joined #dri-devel
fxkamd has joined #dri-devel
iive has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<Lyude>
danvet: no? I always use dim, and I only removed the topic branch for myself I'm fairly sure
<Lyude>
and yes - I can take a look at that today
camus1 has joined #dri-devel
slattann has quit []
camus has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
markyacoub has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
<imirkin>
i don't suppose some poor soul has written a texture gather lowering pass for the hw quirk where only float formats may be used for gathering? (so it has to undo unorm -> float and so on)
<imirkin>
i.e. for int textures, they have to be textured as unorm (or float)
<imirkin>
iirc r600 had a similar problem
<danvet>
Lyude, we figured it out, it was dim remove-branch failing halfway through for jani
<danvet>
I just didn't know what was going on (there's no logs for who deletes the branch you can just grab) and we chatted about deleting some of these topic branch, so I figured I'll ask
gawin has joined #dri-devel
reductum has quit [Ping timeout: 480 seconds]
<Lyude>
danvet: gotcha
ngcortes has joined #dri-devel
reductum has joined #dri-devel
INTL has joined #dri-devel
ybogdano has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
fxkamd has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
camus1 has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
milkylainen has quit [Quit: Connection closed]
fxkamd has joined #dri-devel
pushqrdx has joined #dri-devel
<mattst88>
jekstrand: what is 'dozen'?
<Sachiel>
12
rasterman has joined #dri-devel
<imirkin>
unless there's a baker involved
<imirkin>
then it's 13
<mattst88>
some d3d12-related thing, maybe?
gawin has quit [Ping timeout: 480 seconds]
<Sachiel>
great name, no one will ever be able to google for issues with it
<Sachiel>
oh, Vulkan ON direct12? Why?
slattann has quit []
ybogdano has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
<jenatali>
mattst88: It's the clever name that Collabora picked for a Vulkan-on-D3D12 mapping implementation
<jenatali>
In practice, outside of source code directories, I expect it'll probably be called "VulkanOn12" (following our 'grand' naming traditions :P)
<mattst88>
ah ha. thanks!
<mattst88>
so this is something that's planned for integration into mesa?
<jenatali>
That's pretty out-of-date though, it needs a significant update, there's more work going on in a separate fork
<mattst88>
heh, I'll add the 'dozen' label to it :)
<jenatali>
Oh, someone added a label, huh
nchery has quit [Quit: Leaving]
ybogdano has joined #dri-devel
anarsoul|2 has joined #dri-devel
anarsoul has quit [Ping timeout: 480 seconds]
anarsoul|2 has quit [Remote host closed the connection]
anarsoul has joined #dri-devel
macromorgan has joined #dri-devel
<airlied>
dcbaker: what's the blocker on the mesa release?
<airlied>
like I see the issues filed, but if there is no engineering resources to actually look at them, then maybe they aren't blockers
fxkamd has quit []
JohnnyonF has joined #dri-devel
<kisak>
^ maybe intended for eric_engestrom if the question was for 21.3.0?
milkylainen has joined #dri-devel
<airlied>
oops sorry
<airlied>
eric_engestrom: ^
JohnnyonFlame has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
<eric_engestrom>
airlied: there's a large number of intel regressions (#5533/#5534/#5535), but ngcortes & ybogdano are looking into them now, and I've told them that unless they get back to me by then, tomorrow's release will be 21.3.0 final
<airlied>
cool
<eric_engestrom>
I think there was a bit of an issue prioritizing looking into these reports, and I should probably have pushed earlier instead of waiting :)
rgallaispou has joined #dri-devel
<jekstrand>
jenatali: Yeah, I hadn't realized it wasn't actually merged.
<jekstrand>
So I added a label
<jekstrand>
because I was making an issue
<jenatali>
jekstrand: Cool, thanks!
nchery has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
rgallaispou1 has joined #dri-devel
camus has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.3]
camus1 has quit [Read error: Connection reset by peer]
rgallaispou has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
gouchi has quit [Remote host closed the connection]
ngcortes has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
pushqrdx has quit [Ping timeout: 480 seconds]
pushqrdx has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
rgallaispou has quit [Read error: Connection reset by peer]
jewins has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
mclasen has quit []
mclasen has joined #dri-devel
khfeng has joined #dri-devel
mclasen has quit []
rgallaispou has quit [Read error: Connection reset by peer]
mclasen has joined #dri-devel
pcercuei_ has quit []
dianders has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
oneforall2 has quit [Quit: Leaving]
vivijim has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
pushqrdx_ has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
pushqrdx has quit [Ping timeout: 480 seconds]
nchery has quit [Quit: Leaving]
jkrzyszt has joined #dri-devel
rasterman has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
JohnnyonF has quit [Remote host closed the connection]