ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
mclasen has joined #dri-devel
<graphitemaster>
glMemoryBarrierByRegion is confusing but also, is mesa's implementation even correct? It looks to just forward it directly to regular glMemoryBarrier, meaning the optimization of it doesn't really ever happen
<imirkin>
correct.
<imirkin>
i.e. mesa's implementation is correct, and it's correct that the opt never happens
<ccr>
"technically correct is the best kind of correct"?
<imirkin>
true. but this is also practically correct.
<HdkR>
Correct but not optimized
<imirkin>
iirc it's not extremely clear how to take advantage of the opt
<ccr>
could be that the optimization would turn into un-optimization in practice?
<graphitemaster>
Trying to find the extension this came in to read more about the purpose of it. My guess is it's for TBDR hardware and would benefit greatly on NV (as I'm seeing in the proprietary implementation right now where MemoryBarrier is about 40us and MemoryBarrierByRegion is non-measurable)
<graphitemaster>
It says nothing more than the documentation does lol
<imirkin>
iirc that became core in GL 4.5
<graphitemaster>
I've been going down the barrier rabbit hole this week, making sure I'm getting them right, fully understand them, and performance profiling the effects of them on six different classes of hardware
<imirkin>
sounds like a fun time
<graphitemaster>
Well it would be more fun if Mesa did something with it other than make it an alias for the regular barrier call :X
<graphitemaster>
But from my tests (excluding Mesa) the only hardware I've measured any difference on is NV
<graphitemaster>
Even fucking Mali it does not seem to matter
<graphitemaster>
Which blows my mind because it looks like it exists specifically for mobile TBDR :D
<graphitemaster>
Anyways there does seem to be some very strange behavior with MemoryBarrierByRegion and InvalidateFramebuffer on NV
<graphitemaster>
As in I think I might've found a driver bug
<imirkin>
wouldn't be extremely surprising
<imirkin>
note that InvalidateFramebuffer is slightly subtle too
<imirkin>
can't imagine it would do too much on NV
<imirkin>
maybe allow some render to not have to serialize
<graphitemaster>
FBO invalidation makes a pretty big difference on Volta+ when it comes to tiled resources
<graphitemaster>
Mind you attaching a sparse texture to an FBO is totally something not supposed to be supported by GL
<graphitemaster>
But well, NV is like #yolo
<graphitemaster>
Or maybe they should I guess
<graphitemaster>
* Reads and writes through framebuffers shall have no adverse effect,
<graphitemaster>
framebuffer still execute to completion. Visible side effects
<graphitemaster>
of these shaders such as operations on atomic counters, storage
<graphitemaster>
but fragment shaders corresponding to uncommitted regions of the
<graphitemaster>
blocks or committed regions of images are still seen, as are
<graphitemaster>
the results of operations such as occlusion queries.
<graphitemaster>
Okay well, sparse + memorybarrierbyregion + invalidateframebuffer is totally broken on NV then
<graphitemaster>
Since that is noot actually behaving how I'd expect or how that specific wording is written
<graphitemaster>
sparse + memorybarrier + invalidateframebuffer works fine, so what ever optimization "byregion" does with invalidate on sparse is behaving all weird.
<graphitemaster>
I guess mesa's default everything to memorybarrier is a smart thing, saves you what ever hell that specific combination is doing
urja has quit [Ping timeout: 480 seconds]
iive has quit []
eukara has quit []
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
eukara has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
tommi has joined #dri-devel
Surkow|laptop has quit [Server closed connection]
Surkow|laptop has joined #dri-devel
tommi has quit []
sdutt has quit [Ping timeout: 480 seconds]
maxzor is now known as Guest1973
maxzor__ is now known as maxzor
anholt has quit [Read error: Connection reset by peer]
bbrezillon has quit [Read error: Connection reset by peer]
mripard has quit [Read error: Connection reset by peer]
anholt has joined #dri-devel
mripard has joined #dri-devel
bbrezillon has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
i-garrison has quit [Server closed connection]
i-garrison has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
lemonzest has joined #dri-devel
JohnnyonFlame has joined #dri-devel
hch12907_ has quit [Read error: Connection reset by peer]
i-garrison has quit []
i-garrison has joined #dri-devel
haasn has quit [Server closed connection]
haasn has joined #dri-devel
urja has joined #dri-devel
enunes has quit [Server closed connection]
enunes has joined #dri-devel
mlankhorst has joined #dri-devel
Erandir has quit [Server closed connection]
aravind has joined #dri-devel
evadot has quit [Server closed connection]
evadot has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
kts has joined #dri-devel
dafna2[m] has quit [Server closed connection]
dafna2[m] has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Duke`` has joined #dri-devel
gouchi has joined #dri-devel
Duke`` has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
MrCooper has quit [Server closed connection]
MrCooper has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
* sravn
thinks we need a drm_bridge_helper.c - bridge helpers are implemented in different files which does not help the overview
dviola has quit [Quit: WeeChat 3.4]
kts has joined #dri-devel
lileo___ has joined #dri-devel
lileo__ has quit [Read error: Connection reset by peer]
Ristovski has quit [Server closed connection]
Ristovski has joined #dri-devel
JoshuaAshton has quit [Server closed connection]
JoshuaAshton has joined #dri-devel
JohnnyonFlame has joined #dri-devel
tpalli has quit [Server closed connection]
tpalli has joined #dri-devel
tjaalton has quit [Server closed connection]
tjaalton has joined #dri-devel
Thymo has quit [Ping timeout: 480 seconds]
Thymo_ has joined #dri-devel
Company has joined #dri-devel
kts_ has joined #dri-devel
Thymo_ has quit [Read error: Connection reset by peer]
Thymo has joined #dri-devel
hch12907 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts_ has quit [Ping timeout: 480 seconds]
rellla has quit [Server closed connection]
hch12907_ has joined #dri-devel
rellla has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #dri-devel
hch12907__ has joined #dri-devel
hch12907_ has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
karolherbst has quit [Server closed connection]
karolherbst has joined #dri-devel
alatiera has quit [Server closed connection]
alatiera has joined #dri-devel
Viciouss5 has quit [Server closed connection]
Viciouss5 has joined #dri-devel
frothy has joined #dri-devel
nniov has joined #dri-devel
nniov has quit [Remote host closed the connection]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
danvet has joined #dri-devel
frothy has quit []
Major_Biscuit has quit [Ping timeout: 480 seconds]
Guest1973 is now known as maxzor
shoragan has joined #dri-devel
Major_Biscuit has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
hch12907__ is now known as hch12907
gouchi has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
<hakzsam>
anholt: it seems that deqp-runner 0.11.0 fails to parse a bunch of results for recent CTS like 1.3.1.0 and it reports a bunch of Missing tests, is this something you know already?
gouchi has joined #dri-devel
Haaninjo has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
The_Company is now known as Company
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
<sravn>
emersion: Thanks for a great FOSDEM talk!
<emersion>
glad you liked it :)
aravind has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
asconcepcion has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
dliviu has joined #dri-devel
Major_Biscuit has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
Major_Biscuit has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
iive has joined #dri-devel
<imirkin>
is there a list of talks / videos available from fosdem somewhere?
<imirkin>
(graphics talks, that is)
JohnnyonFlame has quit [Ping timeout: 480 seconds]
* alyssa
is curious how perf compares native fdno vs fdno vm passthrough vs virgl with fdno host
<robclark>
yup
<robclark>
glmark2 isn't the best benchmark, but ~50% faster than virgl
<alyssa>
Woo
<robclark>
still needs a bit of work to get it running in arcvm where more games and benchmarks are avail
<alyssa>
but still slower than native I have to assume
<robclark>
well, on x11 fps is capped at 120fps because of how DIRTY_FB works.. so technically it is faster than native :-P
* robclark
needs to resurrect kernel patch to make DIRTY_FB not stall on video mode panels
<HdkR>
+1 to that
<robclark>
but I think it should be able to get pretty close to native most of the time
<alyssa>
robclark: hehehe
<graphitemaster>
Might be a dumb question. Is there a "preferred sampler state" for a texture that will only ever be sampled with texelFetch. It's kind of strange that you have to set some sampler state on a thing that is never actually using any of the state
calebccff has joined #dri-devel
anujp has joined #dri-devel
<calebccff>
Hi all, I've been doing some work on the PineNote E-ink tablet, it now runs mainline and exposes it's display as a DRM device. e-ink panels usually support several different update modes to optimise for actions like scrolling or animations
<calebccff>
So I've been thinking about the best way to expose that to userspace. At the minute I'm considering creating a new eink class device, so eink panel drivers would register as an eink device and use this interface to let userspace set the update mode, trigger refreshes etc
<calebccff>
Has anyone considered this work before? Or have any ideas on the best way to do this?
<robclark>
I suppose one option would be driver specific ioctls on the drm device?
martijnbraam has joined #dri-devel
<emersion>
calebccff: is it really that different from other DRM devices?
<calebccff>
robclark: that sounds sensible, we would want some kind of generic API for e-ink devices, where the driver is responsible for implementing that API
<emersion>
exactly what kind of stuff would be added?
<emersion>
DRM gives you a FB, a source rect, damage info
<calebccff>
emersion: for e-ink you need to choose how you update the display based on what's happening, e.g. for scrolling you use a fast mode which is smoother but smeary (and then do a full blinky refresh once scrolling is finished)
<emersion>
i'd suggest starting off a dri-devel email thread
<emersion>
ideally with a list of the e-ink specific optimizations you'd want
<calebccff>
emersion: hmm kms properties seem interesting, i don't have very much knowledge of DRM/KMS, would we be able to then have some e-ink framework to expose some pre-defined properties, and have drivers hook on writes?
<calebccff>
(so that userspace can trigger a full refresh for example)
<calebccff>
ok, I can do that
<emersion>
calebccff: yeah, the whole display pipeline state is managed through properties, updated with an atomic commit
<emersion>
in an ideal world none of this would be specific to this particular driver, and the next driver would be able to expose the same uAPI
<emersion>
but maybe it's a bit too soon for this
<calebccff>
emersion: thanks. For scrolling it's not an issue of pushing the data to the panel, it's just that depending on the refresh mode it might look terrible or be slow because the panel is doing full black/white/black flashes to update
<emersion>
ah i see
<emersion>
makes it easier then :)
<robclark>
fwiw, as far as framework and driver code.. probably try to get the uapi right first.. the kernel part can always have helpers refactored out later when more drivers show up
<calebccff>
definitely we need some kind of generic e-ink framework, pretty much all panels support the same kind of modes, just sometimes implemented in different ways, e.g. the remarkable 2 apparently uses DSI for it's panel
<robclark>
and yeah, discussion on dri-devel list is probably a good idea
<emersion>
cool
<calebccff>
alright, thanks. KMS properties seem quite sensible, could you point me to how those are exposed the userspace?
<emersion>
KMS properties can be enums, which advertise a list of possible values user-space can pick from
<emersion>
seems like a new KMS enum on the CRTC could be a good fit
<calebccff>
just being able to set the refresh mode and manually trigger a panel refresh is a good start, userspace can handle the rest for now at least :D
<calebccff>
emersion: ah cool, thanks, can I use libdrm to interact with them?
<emersion>
yes
* sravn
seeing test-drm_plane_helper.c:223:1: error: the frame size of 1488 bytes is larger than 1024 bytes
* sravn
wonders if anyone else see this - when doing arm cross builds?