ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
gawin has quit [Ping timeout: 480 seconds]
Guest958 has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
unerlige2 has quit [Ping timeout: 480 seconds]
q66 has joined #dri-devel
aswar002 has quit [Ping timeout: 480 seconds]
rsripada has quit [Ping timeout: 480 seconds]
Guest957 has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
mdnavare has quit [Ping timeout: 480 seconds]
jhli has quit [Ping timeout: 480 seconds]
dsrt^ has joined #dri-devel
dsrt^ has quit [Remote host closed the connection]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Ping timeout: 480 seconds]
mdnavare has joined #dri-devel
jhli has joined #dri-devel
rsripada has joined #dri-devel
dolphin` has joined #dri-devel
sdutt__ has joined #dri-devel
dolphin is now known as Guest962
dolphin` is now known as dolphin
Ryback_ has joined #dri-devel
unerlige4 has joined #dri-devel
Guest962 has quit [Ping timeout: 480 seconds]
unerlige3 has quit [Ping timeout: 480 seconds]
Ryback_[WORK] has quit [Ping timeout: 480 seconds]
mdnavare_ has quit [Ping timeout: 480 seconds]
sdutt_ has quit [Ping timeout: 480 seconds]
jhli_ has quit [Ping timeout: 480 seconds]
rsripada_ has quit [Ping timeout: 480 seconds]
aswar002 has joined #dri-devel
mattrope_ has joined #dri-devel
pzanoni` has joined #dri-devel
ramaling_ has joined #dri-devel
toolchains has joined #dri-devel
pzanoni has quit [Ping timeout: 480 seconds]
aswar002_ has quit [Ping timeout: 480 seconds]
mattrope has quit [Ping timeout: 480 seconds]
ramaling has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
idr has quit [Quit: Leaving]
ngcortes has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
unerlige4 has quit [Remote host closed the connection]
unerlige4 has joined #dri-devel
toolchains has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
toolchains has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Company has quit [Quit: Leaving]
bmodem has joined #dri-devel
lemonzest has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
danvet has joined #dri-devel
lumag_ has joined #dri-devel
saurabhg has joined #dri-devel
cmeissl[m] has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
jernej_ is now known as jernej
ahajda has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
<emersion>
why do i always pick controversial patches when deciding to write a kernel patch ;_;
toolchai_ has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
<emersion>
jekstrand, danvet: oh well, seems like sysfs won't do
<danvet>
emersion, ?
<emersion>
it'll be very ugly to use that from my user-space, so i think i'll pass
<emersion>
(danvet, sysfs to check for import/export ioctl)
<danvet>
emersion, hm why?
alanc has quit [Remote host closed the connection]
<emersion>
greg says no
<emersion>
so i guess it's a no
alanc has joined #dri-devel
<danvet>
emersion, gregkh is occasionally just wrong
<danvet>
if his objections is all there is, I can jump in an argue a bit
<emersion>
i mean i can understand where he's coming from
<emersion>
and it's not the end of the world
toolchai_ has quit [Ping timeout: 480 seconds]
<dj-death>
danvet: you have any thoughts on my last comment on the VM_BIND design series?
<danvet>
dj-death, haven't looked yet
<emersion>
thanks danvet!
<emersion>
if that doesn't get merged, how bad would it be to check for the kernel version?
<danvet>
emersion, really frowned upon because backports or frankenstein distros like rhel
<emersion>
ack
<danvet>
emersion, but yeah maybe reply to that thread that your plan C is to just check the kernel version
<danvet>
that should annoy gregkh enough that he'll work on a solution :-)
<emersion>
i'm also concerned about e.g. FreeBSD
<danvet>
emersion, do they have dma-buf?
<emersion>
yea
<airlied>
but not sysfs?
<danvet>
hm I guess might need a freebsd specific check there
<danvet>
or they do the getparam on the drmfd
<danvet>
but that just feels so wrong and is guaranteed to trip up rhel style backports
<emersion>
they have a sysfs compat thing, but not sure it's always on
<airlied>
you could just make it a drm fd thing
<airlied>
danvet: we do backport dma-buf as well, but yeah trip wire alright
<danvet>
airlied, yeah but then you backport drm but not dma-buf and boom
maxzor has joined #dri-devel
<airlied>
danvet: could write it into a value from the dma-buf side
<danvet>
lo
marex has quit [Ping timeout: 480 seconds]
<airlied>
I should stop before I suggest using udmabuf
<emersion>
ahah
JohnnyonFlame has quit [Read error: Connection reset by peer]
<javierm>
emersion, danvet: how horrible would be for the DRM core to fill a DRIVER_HAVE_SYNC_IMP_EXP cap or something like that ?
<javierm>
that way you will only need one step at least
<danvet>
javierm, imo pretty horrible, but it's plan B if gregkh doesn't come up with something
<javierm>
danvet: ah, I read your email now. Yeah, it is a layering violation :/
<airlied>
hmm is one of the operations a drm operation?
<airlied>
or is it all dma-buf side?
<javierm>
danvet:, emersion: and what about using configfs for this? i.e: mkdir /sys/kernel/config/dma-buf/ && cat /sys/kernel/config/dma-buf/caps && rm -r /sys/kernel/config/dma-buf/ ?
<emersion>
airlied: all self-contained dmabuf stuff
<emersion>
javierm: greg's point is mostly "all ioctls must only be discovered by trying the ioctl and nothing else"
<javierm>
emersion: well, I think that's his argument to push back on adding random entries to sysfs
<javierm>
since it's supposed to be a filesystem-view of the linux device model
q66 has quit [Quit: No Ping reply in 180 seconds.]
Danct12 has joined #dri-devel
q66 has joined #dri-devel
Company has joined #dri-devel
frieder has quit [Remote host closed the connection]
<jekstrand>
emersion, danvet: Driver side, allocating a BO to test isn't horrible. It's a bit of a layering violation with the way the WSI code is currently designed but I can fix that if needed.
<jekstrand>
We can move the test to to swapchain creation or just go back to the very dynamic on-demand thing I had.
<jekstrand>
But if a client is trying to decide on vulkan vs. GL or something similarly major then oof.
<jekstrand>
I guess maybe you could allocate a dumb BO and then maybe you could do it all with core DRM calls and not have to know what driver you're on?
<emersion>
dumb BOs can only be allocated by the DRM master, with a DRM master FDS
<emersion>
FD*
<jekstrand>
:(
<jekstrand>
Worst case, if gregkh won't let us do anything more sensible than "just try it", it's an initialization cost so maybe compositor start-up takes a few more ms.
<emersion>
nah
<jekstrand>
But it's still pretty horrible.
<emersion>
i'll just not use it
<emersion>
and stick with implicit sync
<jekstrand>
:'(
<emersion>
this trashes my library design
<jekstrand>
Yeah
<emersion>
where the backend (KMS), renderer (GL/Vulkan), and allocator (GBM) are completely separate
<jekstrand>
Which one needs the ioctl?
bmodem has quit [Ping timeout: 480 seconds]
<emersion>
the Vulkan renderer (which could do an alloc) and the completely standalone helper which gives a syncobj from/to a DMA-BUF
<emersion>
(helper just has access to a wayland object and the DMA-BUF, uses the explciit sync protocol to get a fence, falls back to DMA-BUF extraction otherwise)
<emersion>
explicit*
<jekstrand>
Ah
<jekstrand>
And what would that helper do if it detects the ioctl isn'r present?
<jekstrand>
*isn't
<emersion>
it wouldn't advertise support for the explicit sync protocol
<emersion>
and would fail any call to get a fence
<jekstrand>
I'm confused how that all fits into your library hierarchy.
<jekstrand>
Advertising protocols is pretty core to a Wayland compositor.
<emersion>
wlr_linux_explicit_synchronization_v1_create advertises support for the explicit sync protocol
<emersion>
wlr_linux_explicit_synchronization_v1_signal_surface_timeline() and wlr_linux_explicit_synchronization_v1_wait_surface_timeline() fetch and return a fence via the protocol
apinheiro has quit [Ping timeout: 480 seconds]
<emersion>
except if the client doesn't support explciit sync they import/export to the DMA-BUF implicit fence
<emersion>
if the IOCTL isn't available, wlr_linux_explicit_synchronization_v1_create() would just fail
<emersion>
and the compositor would continue to run with explicit sync disabled
<jekstrand>
Yeah, there's no clean way to detect it from that part of the library. You could make "must have this ioctl if you create one of these" be part of the library contract.
<emersion>
yeah, or i could take a wlr_allocator to allocate a buffer and check
<jekstrand>
Yeah
<emersion>
but honestly, i'd just work on something else than expose a bad API
<jekstrand>
idk that "wlr_allocator_has_dmabuf_explicit_sync() must return true if you're going to use this" is any worse than failing creation, TBH.
<jekstrand>
But it's not my API. ¯\_(ツ)_/¯
sdutt has joined #dri-devel
heat has joined #dri-devel
bmodem has joined #dri-devel
ella-0 has joined #dri-devel
ella-0_ has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
deathmist has quit [Remote host closed the connection]
deathmist has joined #dri-devel
karolherbst_ has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
idr has joined #dri-devel
apinheiro has joined #dri-devel
saurabhg has quit [Read error: Connection reset by peer]
rgallaispou has quit [Read error: Connection reset by peer]
whald has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
jkrzyszt has quit [Ping timeout: 480 seconds]
Terman has joined #dri-devel
lumag_ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
jagan_ has joined #dri-devel
pzanoni` has left #dri-devel [#dri-devel]
pzanoni has joined #dri-devel
karolherbst_ is now known as karolherbst
rkanwal has joined #dri-devel
rkanwal has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
JohnnyonFlame has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
ajax: is thumbs-up emoji an ack? :-p
mbrost has quit [Remote host closed the connection]
<ajax>
sure why not
mbrost has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Duke`` has quit [Ping timeout: 480 seconds]
idr has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
camus1 has joined #dri-devel
<alyssa>
\o/
camus has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
pixelcluster has quit [Ping timeout: 480 seconds]
`join_subline has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
toolchains has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
<idr>
NIR_DEBUG=print will help track down which pass is doing the damage.
<idr>
s/will/might/
<jenatali>
Yeah I know which pass is doing the damage...
<jenatali>
Man tessellation shaders are a mess of differences between the two APIs, I'm surprised I didn't see this sooner
<idr>
I think you meant to say, "Tessellation shaders are a mess." :)
<jenatali>
Sure
apinheiro has joined #dri-devel
<jenatali>
idr: I think I might just end up baselining this for now... the problem is an SSA value that's created after the first load_invocation_id, used before a barrier, then used again after a barrier
<jenatali>
The way I have to munge the shaders ends up putting the before-barrier and after-barrier into separate loops, and then the SSA created in the first loop doesn't dominate all code in the second loop
<idr>
Ouch.
<jenatali>
Yeah... and only for code that leads up to storing a patch constant, where D3D only runs that code once instead of per-invocation, so I have to manually loop it to generate the different invocation IDs
<jenatali>
So yeah, assuming that's the only failing test just go ahead and update the CI fails to include that in the baseline
lumag_ has joined #dri-devel
toolchains has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<Kayden>
I'm thinking about closing all Mesa bug reports with labels [bugzilla][Needs Information], which also implies label [i965]. There are reports of...1 intermittent test failure, 1 crash, 1 assert fail, 3 possible misrenderings, and the other 183 are GPU hang reports mostly on older hardware
<Kayden>
that's...about 6.5% of the open bugs
<jekstrand>
Do it
<Kayden>
It's...well...i965 isn't in tree anymore. There may still be hangs, but reproducing them with either latest amber or crocus would be the thing to do.
<Kayden>
And I don't think we're likely to actually investigate any of those given that it's been over 2 years
<Kayden>
so just declare bankruptcy there
<zmike>
do it
<Kayden>
might close some more i965 ones without the needs information tag
<Kayden>
at least for ancient hangs
<Kayden>
(still bugzilla migrated)
<anholt>
+1
<zmike>
mareko: rb update on the counter MR?
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Mamta_ has joined #dri-devel
toolchains has joined #dri-devel
<alyssa>
Kayden: declare bankruptcy, poetic! :p
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
mamta has joined #dri-devel
camus1 has joined #dri-devel
mamta has quit []
rasterman has quit [Quit: Gettin' stinky!]
camus has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
* Kayden
closes feature requests for i915c
<airlied>
my mesa mailbox just got kayden'ed
<kisak>
the king is dead, long live crocus?
<kisak>
ah right, i915
ybogdano is now known as Guest1036
ybogdano has joined #dri-devel
<idr>
Kayden: Are those features i915g has?
<alyssa>
Isn't the point of amber that it's not getting new features?
mattst88_ has quit []
<Kayden>
airlied: sorry about that
mattst88 has joined #dri-devel
<anholt>
i915g has plenty to work on without people's feature requests from 10 years ago that nobody's going to look at clogging up the issues.
<alyssa>
:100:
<Kayden>
yup
<idr>
I was just curious. Geez.
<alyssa>
Arff!
<Kayden>
idr: I don't believe so, no. They were saying the HW supported 10bpc formats and Mesa didn't expose that.
<Kayden>
but at the time i965 didn't even expose it
<Kayden>
later on patches got added I think
<Kayden>
it could probably get added...if anybody cares
<anholt>
i915g already does 10bpc :)
<Kayden>
ah. well, then :)
<Kayden>
upgrade mesa problem solved
<Kayden>
also if you're using i915 class hardware, the missing 2 bits is probably not your biggest problem :D
pcercuei has quit [Quit: dodo]
Guest1036 has quit [Ping timeout: 480 seconds]
<alyssa>
Kayden: I always want to spend more time on old hardware :(
<alyssa>
I think lima is so cool, how much it's still improving
gawin has joined #dri-devel
<idr>
Some old hardware is cool.
<idr>
And then there's i915.
anujp_ has quit [Ping timeout: 480 seconds]
<alyssa>
heh
<Kayden>
Yeah, if it's old yet people are still actively working on it, great
<Kayden>
For drivers that haven't really seen active work since I started working on Mesa and no longer exist in tree...that's a bit different :)
<alyssa>
I said old hardware, not old drivers ;)
<alyssa>
I like crocus :-D
heat has quit [Remote host closed the connection]
<gawin>
bonjour, I'm bumping question if support for loops in fragment shaders is obligatory for es 2.0?
<anholt>
gawin: dynamic looping (non-unrollable) looping is not required, but you have to throw a link error if you can't do it
<anholt>
see i915_check_control_flow()
<gawin>
thx
ybogdano is now known as Guest1037
ybogdano has joined #dri-devel
<gawin>
recently r400 is able to run full deqp-gles2's suit without crashing ^^
toolchains has quit [Ping timeout: 480 seconds]
anujp_ has joined #dri-devel
Guest1037 has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
<anarsoul>
does gallium driver have to do something special in order for mesa to do msaa resolve? I'm trying to debug dEQP-GLES2.functional.multisample.num_samples_polygon on lima
<anarsoul>
what I see is that it does the rendering into MSAA buffer, but it's never resolved
ngcortes has joined #dri-devel
<alyssa>
anarsoul: what do you mean?
<alyssa>
MSAA in GLES3 at least is unresolved
<alyssa>
resolving happens with a blit
<anarsoul>
it's GLES2
<alyssa>
u_blitter can do it
<alyssa>
I assume GLES2 is an extension matching GLES3 semantics?
<airlied>
yeah you get a blit from state tracker with src n samples, dst 1 sample
<anarsoul>
well, I don't get a blit (I have lima-specific blitter)
<anarsoul>
alyssa: on GLES2 backbuffer is multisampled, frontbuffer isn't, resolve is supposed to be done on flip
<alyssa>
"I have lima-specific blitter" might be wrong
<anarsoul>
alyssa: not really, it's not even getting called
<alyssa>
:|
<anarsoul>
yeah
<anarsoul>
that's what puzzles me :)
<jenatali>
Having a surface with different MSAA levels between front and back sounds wrong to me
<alyssa>
pardon the question but why do you want real MSAA on Lima?
<alyssa>
Perf is going to suck. Like, even on the latest Malis, "real" MSAA perf sucks.
<alyssa>
(EXT_ms_rtt is what you want but that's not core API)
<anarsoul>
alyssa: I know, but there's no shortcuts in mesa besides PIPE_CAP_SURFACE_SAMPLE_COUNT, right?
<alyssa>
for EXT_ms_rtt, you have surface->nr_samples > 1 but surface->texture->nr_samples = 1
<alyssa>
and there's no blit
<alyssa>
and you're expected to resolve inline on writeout, which is trivial on Midgard and probably also Lima
<alyssa>
otherwise there should be a blit
<alyssa>
nothing to do with front vs back, there
<anarsoul>
alyssa: yeah, it's already handled and dEQP-GLES2.functional.multisampled_render_to_texture.* passes
<anarsoul>
"f you create a multisampled Default Framebuffer, the back buffer is considered multisampled, but the front buffer is not. So swapping the buffers is equivalent to doing a multisample resolve operation."
<jenatali>
Huh. Weird
<alyssa>
state tracker should be giving you a blit then
<alyssa>
in Gallium, everything is an FBO
<alyssa>
there are no front buffers*
<alyssa>
* unless you're a weird software driver
<anarsoul>
alyssa: it doesn't give me a blit :\
<anholt>
anarsoul: does lima really not support PIPE_CAP_SURFACE_SAMPLE_COUNT?
<anarsoul>
cbuf->nr_samples is 0, cbuf->texture->nr_samples = 4, so I don't do inplace resolve
<anarsoul>
anholt: hw supports inplace resolve if you're asking about that
<anholt>
yeah. "render multisample in your tiled buffer, resolve on writeout to memory"
<anarsoul>
I'm debugging a failure of the test that doesn't do in-place resolve
<anholt>
if your hardware can do that, then you really want to be setting that pipe cap, and you won't get a blit for the resolve.
<anholt>
at which point I would expect for msaa you have cbuf->nr_samples=4 and cbuf->texture->nr_samples=0/1 (whichever, I forget)
ngcortes has quit [Ping timeout: 480 seconds]
<anarsoul>
anholt: I think that's only true for EXT_multisampled_render_to_texture
<anholt>
you would also get it for winsys msaa.
<anholt>
and in gles2 you don't have a way to make msaa user renderbuffers/textures without EXT_ms_rtt
mhenning has joined #dri-devel
<anarsoul>
heh, so how does dEQP-GLES2.functional.multisample.num_samples_polygon work? :)
<anarsoul>
or rather any test from dEQP-GLES2.functional.multisample.*
<anholt>
if you don't have a winsys msaa buffer, "NotSupported (No multisample buffers)."
<anholt>
(that's surfaceless there)
<anholt>
but if you have an msaa pbuffer/window, then I would expect cbuf->nr_samples=4 and cbuf->texture->nr_samples=0/1
<anarsoul>
I get cbuf->nr_samples = 0 and cbuf->texture->nr_samples = 4
<anholt>
are you setting the cap?
<anarsoul>
yes
<anholt>
--deqp-surface-type=?
<anarsoul>
--deqp-gl-config-name=rgba8888d24s8ms4
<anarsoul>
surface-type=pbuffer
<anholt>
EGL platform?
ngcortes has joined #dri-devel
<anarsoul>
surfaceless
<anholt>
wat. how are you making a pbuffer with surfaceless? did we change something?