<anholt>
Kayden: thanks for sorting out an intel flake marker!
<Kayden>
heh, least I can do
<Kayden>
just need to learn the system a bit better
<anholt>
all: vulkan cts uprev MR is up at !14920. would love anyone to review it and push it along, I'm feeling more under the weather again and might be done working for a bit. (woo covid)
<Kayden>
! :(
<Kayden>
hope you feel better soon
<anholt>
Kayden: the iris egl crashes would also be interesting to look into, if you had some bandwidth.
<anholt>
also would love to get asan into the intel pipeline.
<Kayden>
I haven't had a lot of luck looking into those in the past :(
<Kayden>
asan would be great, haven't kept up with that at all
maxzor_ has quit [Ping timeout: 480 seconds]
<Kayden>
anholt: what do you need others to do on the cts uprev MR?
<Kayden>
definitely happy to see the uprev happen
<airlied>
anholt: any idea how much asan is CTS vs driver?
<Kayden>
surprised to see anv crashes on some tests, I know we recently passed 1.3 CTS on those platforms, but maybe some patches got lost in the shuffle
<Sachiel>
is it 1.3.0 or 1.3.1? There were new things going in on 1.3.1 that we are not passing
<Kayden>
ah, that's why
<Kayden>
(it's 1.3.1)
<Sachiel>
we also have some failures from a cts fix from dj-death that didn't make it to 1.3.1
<cheako>
Is there anything I can do to classify semaphores? I'm thinking about looking at the least significant bits in the value Vulcan uses, to try and catch an alignment issue... but I don't think the address, if that number even is an address, to the object effects a semaphore's performance.
tursulin has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
mbrost has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
mbrost has quit [Read error: Connection reset by peer]
iive has quit []
mbrost has joined #dri-devel
<Kayden>
YES
<Kayden>
multiple things marged
<zmike>
Kayden: if you get time can you check out !14878? you were the one who made the pass run originally
<zmike>
I think you probably want either a vulkan channel or a rust channel
ngcortes has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
Kat_Witten has joined #dri-devel
hch12907__ has quit [Ping timeout: 480 seconds]
Kat_Witten has quit []
<imirkin>
zmike: scary to think i would have been the last to touch it. it was _ages_ ago
<zmike>
imirkin: yeah this has the feel of code that everyone's too afraid to tip over
<imirkin>
anyways, i'll try to sort something out tonight. maybe i can convince nouveau to feed it through the translate thing.
<zmike>
nice, thanks
<imirkin>
we do it for the R64_* formats, so R32_USCALED shouldn't be too big a lift
<imirkin>
(p.s. whoever thought the R64_* formats were a good idea ... i disagree.)
<zmike>
at the least it'd be cool to not lose the lower bits there
<zmike>
need those to pass cts
<imirkin>
well, should be straightforward to make it just work properly
<zmike>
yeah
<imirkin>
but it's not completely trivially obvious, so i def want a way to repro first
<zmike>
nice
<imirkin>
(i know, testing fixes before pushing is so passe, but i guess i'm old-fashioned)
<zmike>
well you could just use zink on that test like I suggested
<zmike>
but disabling format support on any driver will also do it
<imirkin>
yeah, but i don't have anything zink-capable here. the gen9 thing is at work. i can try to use it, but might be easier to do it all local
<zmike>
oof how's Debian sarge treating you?
<imirkin>
if that was directed at me, i don't use debian
<zmike>
probably also wouldn't be using sarge since that was like 20 years ago
<imirkin>
ah ok
<imirkin>
the name sounded mildly familiar
jljusten has quit [Remote host closed the connection]
<imirkin>
zmike: `Result vector is equal to [ 0, 4 ], but [ 1, 5 ] was expected.` -- that's a lot like the failure you're seeing right?
<zmike>
yup
<zmike>
that's the exact one
<imirkin>
excellent
<imirkin>
now to go digging in the intel intrinsics guide
<imirkin>
i know the op is there, but who knows what it's called
<imirkin>
heh. AVX512F adds unsigned -> float conversion. good thing every cpu has that...
yogesh_mohan has joined #dri-devel
mbrost has joined #dri-devel
<HdkR>
AVX512 fills a bunch of holes that the previous vector extensions missed. x86 really needs an extension like AVX3 that just brings those in without caring about 512bit registers :|
m has joined #dri-devel
<HdkR>
AVX-maintenance3
ybogdano has quit [Ping timeout: 480 seconds]
maxzor_ has joined #dri-devel
<imirkin>
wtf is the difference between "pand" and "andps" and "andpd"?
<imirkin>
it's doing a bitwise and ... who cares if it's 4x32, 2x64, or 1x128?
<graphitemaster>
Does mesa / linux graphics stack have a device database with like gpu hardware info? like given say a model name query the number of compute units or memory bandwidth it has, or is it still very much just what ever the hardware reports and no info for anything but what hardware you actually have and are using
<airlied>
graphitemaster: the latter
<graphitemaster>
*cries*
<jekstrand>
It's really hard to make a database of that information. On Intel, for instance, chip name doesn't have anything to do with memory bandwidth.
<jekstrand>
That's all about what you've got plugged in
<jekstrand>
On discrete, you can get the same series card with different memory configs depending on card manufacturer
<graphitemaster>
memory bandwidth was just an example, I'd rather mroe just know the number of compute units and "lanes" per simd or what ever something has
<jekstrand>
Number of compute units may be easier but we don't have a database for it.
<HdkR>
It's impossible to maintain to, since your bottlenecks can change so dramatically overtime. Compute or BW might not even be the bottleneck if your shader uses some edge case feature that's slow. :P
<jekstrand>
For Intel, you can look at intel_device_info.c
<graphitemaster>
I don't need it to be accurate - I was just hoping to have at least some information to compare against
<graphitemaster>
Even a window would be fine
<graphitemaster>
LLike oh runs somewhere between 20 GiB/s and 64 GiB/s is already pretty decent
<HdkR>
And then you get something like RDNA2 where your VRAM BW is quite low, but it punches above its weight due to cache :D
<graphitemaster>
This is actually surprisingly not that difficult to do with NV - AMD is a mess, Intel seems the worst :D
<airlied>
wikipedia :-P
<HdkR>
and then Nvidia throws a curveball like the GTX 970 at you
<jekstrand>
Also, your SIMD width on Intel is variable. (-:
<graphitemaster>
My main issue with AMD is how they run backwards in time around the GCN era, like the 520, 530, and 540 RX GPUs all came out the same day, one is GCN 1, the other GCN 3, and then GCN 4 - what is that mess? Also fuckin' HD 7000 series GPUs that are TeraScale 2 instead of GCN. They went forward on GCN, then back to TeraScale, then back on GCN again (four times by my count)
<imirkin>
NVIDIA GT 630 could be fermi, kepler, or kepler2
<graphitemaster>
tl;dr it all went to shit in 2006 XD
<airlied>
graphitemaster: amd often had the low end of a series be an older seres
<airlied>
series
<graphitemaster>
Yeah, I did not know that until the past few days as I've been trying to write up my own database
<airlied>
marketing names are marketing
<graphitemaster>
Made me lost a bit of respect for AMD because it's actually confusing
<airlied>
wikipedia is the answer
<graphitemaster>
And dihonest.
<graphitemaster>
*dishonest
<jekstrand>
And if it's Intel, there are at least 4 different marekting names for each GPU and none of them correlate to any of the others cleanly!
<graphitemaster>
I wrote in work chat
<graphitemaster>
"I seriously think I'm going to find some job recruitment for data analyst at the CIA if I keep going down the AMD product naming and chronology Wikipedia."
<airlied>
yeah I think all of them make up marketing names
<jekstrand>
NVIDIA is the only ones who've actually gotten marketing rightish, IMO.
<airlied>
as imirkin pointed out above, even they do it wrong sometimes
* HdkR
pushes Nvidia's mobile stack under a rug quick.
<vsyrjala>
except for selling ancient gpus under new names. at least that's what i read somewhere
<jekstrand>
HdkR: Well, yeah, no one wants to look at that anyway. :P
<imirkin>
jekstrand: they might get marketing right, but the marketing names have no connection to generation :)
<airlied>
maxwell and maxwell2
<graphitemaster>
The Wikipedia tables for AMD are also quite wrong in some areas which I made no attempt to fix because it's inline HTML + CSS withhin a tiny 400px box on Wikipedia and frankly I'm not a web developer
<jekstrand>
imirkin: Maybe I've just not payed enough attention and got fooled like the rest of the world.
<graphitemaster>
And if it was hard for me to figure it out, it should be hard for others too XD
<imirkin>
jekstrand: exactly. they got marketing right :)
<jekstrand>
imirkin: Yup!
<imirkin>
on average, x50 and up is reliably a fixed generation
<imirkin>
but below x50, it's a mix
<graphitemaster>
I still can't find any consistent information on wave32 / wave64 for AMD GPUs either.
<jekstrand>
imirkin: In that case, maybe Intel got marketing right too if the objective is to maximize your confusion * sales.
<imirkin>
i.e. 650/660/670/680 are all going to be kepler, no matter what
<imirkin>
but 640 and below can be whatever
<graphitemaster>
NV has made a couple miffs
<imirkin>
and like HdkR mentions, on mobile it's actually even more confused
<jekstrand>
Oh, I assume mobile is a disaster always
<graphitemaster>
As someone pointed out to me earlier, the 8800 GT that came in 320MiB and 640MiB flavors, the 8800 Ultra which came in 768MiB flavor and was also released as the 8800 GTX, the 8800 GTS 512MiB however was a GF9 part. So the GTS 512MiB was faster than the GT 640MiB and the GTX 768MiB (aka Ultra 768MiB) and came out later than all of those.
<jekstrand>
It's an axiom of mobile that everything is custom and weird and nothing makes sense.
<imirkin>
like a GTX 750 is maxwell, but GTX 750M can be kepler, among other things
<jekstrand>
:facepalm:
<imirkin>
and a bunch of the 8xx series are kepler too
<imirkin>
or a mix
<graphitemaster>
What is the benefit to doing this, is it just to get rid of stock or something lol.
<imirkin>
graphitemaster: bigger numbers = more sales
<imirkin>
nobody wants a 6xx when the latest is 8xx
<graphitemaster>
Honestly seems like false advertisement to me.
<vsyrjala>
"it's just a number"
<graphitemaster>
When you get the new iPhone it's always a new iPhone, not the old iPhone with a model number change
<jekstrand>
If you have a process bump, often the older process is cheaper and has higher throughput
<jekstrand>
Intel definitely did with 10th generation i-series.
<graphitemaster>
But it's all scuffed.
<graphitemaster>
I tried unscuffing it but got nowhere
<graphitemaster>
I also found errors even in their own data
<jekstrand>
And then there's where you release exactly the same hardware and drop a few "go slow" loops from the driver when you detect that PCI ID. :-D
* maxzor
notes that AMD wikipedia pages need love indeed
shankaru has joined #dri-devel
<graphitemaster>
Add a compute unit count to the table if someone is going to fix the AMD tables on Wikipedia.
<graphitemaster>
The unified shader cores thing doesn't always divide by 64 or what ever into CUs as I found
<tzimmermann>
javierm, those damage rectangles are given in scanline and pixel coordinates. pixels can be in the middle of a single byte. imagine you want to convert pixels 5 to 11 of a scanline. if one of your formats is 1-bit mono, the first and final pixels would be located in the middle of a byte
dviola has joined #dri-devel
<hakzsam>
anholt: something like: ERROR - Failure getting run results: No results parsed. Is your caselist out of sync with your deqp binary? (See "/mnt/mesa/../../mnt/results/cts/c152.r1.log")
<javierm>
tzimmermann: I still don't get it... sorry. How can pixels be in the middle of a single byte if for gray8 is a 1 byte per pixel ?
<javierm>
tzimmermann: if gray8 -> mono conversion is done for pixels 5 to 11, then the bits in the packed mono may start at the end of a byte, but that shouldn't be a problem
<javierm>
one question is if is allowed to convert for scanlines < 8, probably that won't be supported ?
<javierm>
s/at the end/at the middle
<tzimmermann>
javierm, np: 1-bit mono has 1 bit per pixels; so 1 byte contains 8 bit/pixels
<tzimmermann>
right?
<javierm>
tzimmermann: correct
<tzimmermann>
for example, bit/pixel 5 is in the middle of the byte
<javierm>
for mono yes
<tzimmermann>
in the conversion function, if you only have the dst pointer. it can only refer to pixels 0, 8, 16, 24, etc. if you want to refer to pixel 5 you need dst pointing to pixel 0 and an offset into (*dst) so you know that you have to start at bit 5
<tzimmermann>
regarding scalines < 8: 'scanlines' refers to the vertical y axis. so it's not a problem
<tzimmermann>
pixels per scanline refers to the horizontal x axis.
hch12907 has joined #dri-devel
<javierm>
tzimmermann: ah, Ok. I meant pixels for scanline. That is, you can't convert less than 8 pixels since the minimum that you can get for mono is 8 pixels packed in one byte
<tzimmermann>
exactly.
<javierm>
tzimmermann: but now I understand what you mean. If the source isn't 8 pixel aligned, then it's a problem
<pq>
YUV images with odd dimensions are a thing, even if chroma is 2x2 sub-sampled, so...
<tzimmermann>
javierm, for a full solution, we'd need a bit-offset into *src and *dst to know where we start converting
<pq>
I don't see why mono images should be limited to dimensions multiple of 8 either.
<tzimmermann>
pq, it shouldn't. we're talking about limitations of the current api
<pq>
uapi?
<tzimmermann>
pq, no. internal
<pq>
ok, good
<tzimmermann>
javierm, for the usecase of your driver, i'd simply put in a check to ensure that everything is aligned properly. and extend the damage area in your driver
<tzimmermann>
i.e., make x1 a bit lower and x2 a bit higher, if necessary
<javierm>
tzimmermann: I would prefer to extend the API as needed. Since I'm less interested in supporting this particular display but more about making sure that DRM is suitable to port the others
<tzimmermann>
i don't think so
<tzimmermann>
javierm, even better :)
<javierm>
I mean, that was the motivation to buy this panel and start experimenting :)
<javierm>
tzimmermann: so this offset calculation should just be internal to drm_fb_*_to_mono() right ?
<javierm>
drivers that call the helpers to convert to mono shouldn't be aware about this
hch12907 has quit [Ping timeout: 480 seconds]
dos1 has quit [Server closed connection]
dos1 has joined #dri-devel
<tzimmermann>
javierm, if you want to do the full thing, simply add parameters like dbuf_bit and sbuf_bit to the per-line helper
hch12907_ has quit [Ping timeout: 480 seconds]
hch12907_ has joined #dri-devel
hch12907__ has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: yes, only the drm_fb_gray8_to_mono_reversed_line() should be aware of this to shift the bits in the dest bytes as needed
<javierm>
but it's more tricky because this may only be for the start and end dst byte and not in the middle if there are 8 pixels aligned
<javierm>
tzimmermann: anyway, thanks a lot for pointing out this. I didn't notice before that assumption
mstoeckl has quit [Server closed connection]
mstoeckl has joined #dri-devel
narmstrong has quit [Read error: Connection reset by peer]
narmstrong has joined #dri-devel
hwentlan____ has quit [Read error: Connection reset by peer]
<romangg>
Do you think this could be a viable path forward or would you rather go into a different direction?
<romangg>
There is a bit of "vagueness" introduced by Mesa then doing basically the same as some Wayland compositors: delaying the commits based on client processing time but if mesa has not as tight limits that would still work out fine I assume.
<romangg>
It would be nice to also measure the gpu -time though.
Company has joined #dri-devel
pcercuei has joined #dri-devel
<MrCooper>
romangg: yeah, measuring CPU time only may not work well in GPU limited scenarios; other than that, no particular thoughts offhand
itoral has quit [Remote host closed the connection]
<ishitatsuyuki>
romangg: I'm generally not in favor of trying to be "smart" in the drivers — it can potentially benefit a lot of applications, yes, but it can also unintendedly break application assumptions as well
<ishitatsuyuki>
similarly, delaying commits in compositors is a good idea if and only if you have full control over what you render. any assumption over the app's rendering model does not work well
<ishitatsuyuki>
trying to optimizing for games often breaks GUI workloads, because the assumption that apps renders in a busy loop with constant workload doesn't hold for GUI applications that incremenetally render and skip no-change frames
itoral has joined #dri-devel
flacks has quit [Quit: Quitter]
jernej has quit [Server closed connection]
jernej_ has joined #dri-devel
<romangg>
ishitatsuyuki: The current patch at least (thanks to MrCooper's first draft) only tries to be smart when the client saturates the pipeline with no buffer free anymore. So GUI apps should not be impacted.
<romangg>
For Wayland compositors it's nowadays the standard model I would say to try to delay the presentation. Weston does it too.
<ishitatsuyuki>
I'm not criticizing the idea of repaint scheduling itself, but in particular trying to do it dynamically
flacks has joined #dri-devel
itoral has quit [Remote host closed the connection]
<ishitatsuyuki>
but well, it's also largely affected by implicit sync used everywhere so that one needs some fix
itoral has joined #dri-devel
<ishitatsuyuki>
doing repaint scheduling at a fixed margin proportional to refresh period would likely give less headaches
itoral has quit [Remote host closed the connection]
mszyprow has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
<emersion>
that's what weston does
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<ishitatsuyuki>
> With the patch we give the client less than a frame to submit the next one.
<ishitatsuyuki>
This assumption/behavior is problematic because it breaks CPU/GPU pipelining. Latency optimization should only go as far as it does not reduce throughput
itoral has quit [Read error: Connection reset by peer]
<romangg>
emersion: Ah right, I thought it also does some dynamic adjustment to client performance. wlroots is also currently doing it this way, rigth? Plus some configuration value to adjust the delay.
itoral has joined #dri-devel
mclasen has joined #dri-devel
<romangg>
ishitatsuyuki: Why does it break CPU/GPU pipelining to give the client less than a frame to submit the next one?
<romangg>
When the client is slower I assume, right?
<romangg>
But only then. If the client has like 500fps on a 60hz display for example there shouldn't be a problem. Or is there still one?
<ishitatsuyuki>
romangg: because the optimal case is where both the CPU and GPU takes a frame worth of time to do their job?
<ishitatsuyuki>
I still haven't understood what are you trying to measure
<ishitatsuyuki>
measuring is very hard, and can easily run into feedback loops or other instabilities
<ishitatsuyuki>
(in general)
pjakobsson has joined #dri-devel
<daniels>
Kayden: thanks for the flake updates!
Stary has quit [Server closed connection]
Stary has joined #dri-devel
nchery is now known as Guest2225
nchery has joined #dri-devel
Guest2225 has quit [Ping timeout: 480 seconds]
reactormonk[m] has quit [Server closed connection]
reactormonk[m] has joined #dri-devel
<romangg>
ishitatsuyuki: My goal would be to measure how long the client/system needs overall to process a frame so that we can delay this to a point close to vblank for reduced latency. At the moment it's a latency of up to two frames for saturating clients from processing till depication on screen.
<romangg>
MrCooper, ishitatsuyuki: As a compromise would an option be fine to let the compositor (gamescope) switch on/off the delay/block for one frame?
<romangg>
Then I'll throw the logic to measure the client processing time out again.
mriesch has quit [Server closed connection]
mriesch has joined #dri-devel
<ishitatsuyuki>
I guess making it opt-in would be better, but I'm still not convinced that it's the right approach
<ishitatsuyuki>
if it's a game, it's probably much better to set a frame limit instead
<romangg>
ishitatsuyuki: Who would set such a frame limit?
devilhorns has joined #dri-devel
<romangg>
I think the original problem was about games that limit their frames "stupidly" by just using up all available buffers and then waiting for one to become available again.
<daniels>
so I'm going to guess at some kind of API change which isn't handled
CounterPillow_ has quit [Server closed connection]
<daniels>
looks like pytest is installed from Debian, so you'd either have to adapt to handle pytest 7.x, or use pip to install it and force 6.x
CounterPillow has joined #dri-devel
hakzsam has quit [Server closed connection]
hakzsam has joined #dri-devel
<romangg>
MrCooper: Imo from an architectural viewpoint it makes sense to put some more intelligence in the driver if the client is stupid (as your check on the buffers being depleted ensures). But as said, if you don't think it's worth it or too risky I would go for a more lowkey solution with a switch for the compositor to toggle.
linkmauve has joined #dri-devel
Duke`` has joined #dri-devel
<tpalli>
daniels ok, sounds like some fixes needed for piglit to adapt
<pq>
romangg, the only thing I've read is this IRC discussion FWIW, but I'd be wary of optimizing for naive apps due to the risk of also preventing apps from ever becoming smarter. IOW smart apps would need a way to promise they are smart.
<daniels>
tpalli: yeah, though I've never used pytest so have nfi what they are ...
<romangg>
pq: I definitely don't want to prevent apps from becoming smarter haha. :D Do you mean with the promise like a way they can tell the driver to not do any optimizations?
<tpalli>
daniels heh same here
<pq>
something like that, a way to disable driver magic that could get in the way
<pq>
of course, then you will have apps that disable driver magic and are still naive...
<romangg>
I thought it's enough to check if the client depletes all buffers. Could this happen also for "smart" apps?
<pq>
hard to say... what's the limit, 4?
<romangg>
Depends on the gpu I guess. But yea, I think 4 images a swap chain usually provides.
<romangg>
There is also a check for buffer age. If the buffer age is queried at any point in time no optimizations is taking place because that defines a client to be "smart" I guess. :D
<pq>
smart apps may decide to want to minimize latency or maximize throughput, and if they maximize throughput (without wasting drawn frames), they need to be able to fully occupy the whole pipeline from app to compositor to KMS to scanout.
<pq>
and that might take all 4 buffers?
<pq>
more, if they use Wayland sub-surfaces or other future Wayland surface sync extensions
<romangg>
I don't understand how that maximizes throughput or what it means actually. Should I google it or is it quick to explain?
<pq>
the time for a single frame to go through the pipeline may take longer than a single refresh period, so the able to present something new on every refresh, you have to have buffers in flight at each step of the pipeline simultaneously.
<pq>
*so to be able to present
<pq>
that's what I mean with maximizing throughput - not that each frame could be started and finished within one refresh period of time
<pq>
I mean, there are apps that want FIFO instead of mailbox model, too.
<romangg>
ty. right, I always found FIFO to be weird. Why do you want to present something possibly outdated?
<pq>
I dunno. I just recall that people make noise about it.
shankaru has quit [Quit: Leaving.]
<pq>
video playback?
<romangg>
right, but you could do that also with mailbox or immediate if you listen for the vsync. Maybe it's easier with fifo if you know the refresh rate and then just commit buffers according to that in advance.
<romangg>
or just something legacy clients liked to do before mailbox was a thing.
<pq>
I suppose people are accustomed to the old-school swapinterval kind of scheduling.
maxzor_ has joined #dri-devel
<clever>
ive recently made my own 2d gui framework, and i just have a function that requests an update of the screen, and defers the actual update until the next vsync, plus one that can block a thread until vsync
<clever>
so at the start of a frame, the pageflip occurs, and all threads unblock, and you have until the end of the frame to post another pageflip request
<clever>
but i can see how that would cause problems, if you take 1.1 frames to render, it will go down to half the vsync rate
<clever>
a bounded fifo, with vsync based draining would eliminate that
<Company>
that might be preferable though
<Company>
30fps often looks smoother than 60fps with dropped frames
<clever>
yeah, but when you start to go down to 15fps or 7.5fps, dropped frames may be preferable
<Company>
though for gui frameworks, the time to render is usually not constant between frames
<clever>
for a gui framework, id be more inclined to re-render based on a dirty callback, and post an update to take place at the next vsync
<Company>
there's bursts (like when scrolling or opening a sidebar or something big like that) and then there's lots of very little work inbetween
<Company>
depends very much on the kind of gui
<Company>
note: I'm a core GTK developer
<clever>
most of my work has been baremetal, implementing rpi drivers, and RE'ing the linux kms source
<Company>
some guis are very complicated with very little changes (think a file manager that just updates the bg of the file the moust is hovering on)
<Company>
in that case dirty-area based updates are very useful
<Company>
and then there's game-based guis where you have 5 buttons and they are all bouncing around
<clever>
yeah
<Company>
in that case full redraws are perfectly fine
<clever>
one game i was playing with recently, had a full 3d render of a forest in the background of the menu, with branches blowing in the wind
<clever>
but, that was a very handy reference, as the quality took a massive nose-dive when i messed with LOD settings
<clever>
so i could see the impact of my choices, without having to launch into the game itself
robertfoss has joined #dri-devel
zackr has quit [Remote host closed the connection]
<clever>
Company: of note, the 2d composition engine on the rpi is surprisingly powerful, so you could make each window in xorg its own 2d bitmap (xorg already does that when composition is enabled), and then just have the hw combine them for you
<clever>
but there is a limit of about 290 layers, and if you waste bandwidth by covering a pixel multiple times, the hw can be overloaded and not render right
<Company>
yeah, and all of that runs into the problem where you have no idea what applications are gonna try
<clever>
yeah
<clever>
i think in the really old days, each ui element may have been its own XImage
<clever>
but with modern toolkits like gtk, the whole window is one image, and it just renders client-side
<Company>
GTK2 had one X window per element with user interaction
<clever>
ahh
<Company>
a bunch of them did input-only windows
<clever>
so in theory, each element with user interaction could be its own double-buffered bitmap
<Company>
somewhere during GTK 2.X those windows were emulated client-side
<clever>
and the hw could composite things
<Company>
and from GTK 3.X onwards it was all client-side
<clever>
ahhh
<Company>
GTK 4 has to be all client-side because it does rotations and scaling and clipping with rounded corners and all of these fancy modern things
<Company>
that X can't do
<Company>
also blurs and such
<clever>
yeah, the 2d unit on the rpi only has limited flips, and rounded corners are via per-pixel alpha
<clever>
scaling is possible, but i dont see any blur options yet
<clever>
90 degree rotations (axis swaps) are via a secondary stage, which heavily complicates things if you want only certain elements rotated
<Company>
also, you want an animated rotation, where you smoothly animate from 0deg to 90deg
<clever>
but everybody just ignores the 2d core on most gpu's, and throws moar opengl at the problem
<clever>
which can do everything
<pq>
clever, we had a raspberry pi backend for Weston several years ago, which off-loaded every surface (window) to the (proprietary) 2D compositing API. Today, the same could happen on the standard Weston DRM-backend, provided all apps use dmabuf. And I very much remember the bandwidth overload problems.
<Company>
yeah
<clever>
pq: yeah, you would need to detect occluded layers and slice them up, or use the writeback port to pre-render it to a secondary buffer
<clever>
the only real reason i can see to use the 2d core, is that it may result in lower memory bandwidth, and reduced power draw
<clever>
although, memory bandwidth usage depends on how often your redrawing the whole scene
<clever>
if your directly using the 2d composition hw, then the hw will dynamicaly fetch every bitmap as it races ahead of the (virtual) electron beam scanning out the image
<clever>
if your using the writeback port, then you can do that without having to race, but it writes back to ram (more bandwidth), and then you still need to render that as before (more bandwidth)
<clever>
and if your using the 3d core, i guess the memory usage will be the same, possibly a bit lower with the texture caches
<clever>
but texture format changes may add more...
<danvet>
javierm, [PATCH 08/21] fbcon: Use delayed work for cursor <- do you have time to look at this?
<clever>
pq: oh, but i can see a limitation your dispmanx code may have had!
<javierm>
danvet: sure. I'm in a meeting now but will look at it once it finishes
<clever>
pq: yep, even on a pi1
<clever>
pq: this mailbox call returns the handle for the image buffer behind a dispmanx resource, you then pass that to mem-lock (another mailbox), and you get its current physical address, mmap /dev/mem, write directly to it
itoral has quit [Remote host closed the connection]
<pq>
yuck, physical address
<pq>
weston ran as a normal user :-)
<pq>
no root privs
<clever>
yeah
<pq>
so no phys addresses either
<clever>
the modern drm/kms api's hide that from you
<daniels>
that DispManX call also didn't exist at the time
<clever>
daniels: it was added before the pi2 came out i believe
<danvet>
javierm, well no rush, just figured since you've said you plan to look at it
<tintou>
daniels told me that the += 9 was because for some hardware, the VAR0-7 was reserved for point co-ordinate information, I have a piglit test that is actually using GL_MAX_VARYING_FLOATS variables so the 24-31 are too much there, I wonder if GL_MAX_VARYING_FLOATS should have been decreased by 9 in this case (which collides with the documentation requiring at least 32) or if the test was actually missing a check someway
<alyssa>
not really sure how to tag the MR ... it has a behaviour change for the laundry list of drivers that didn't set info.internal correctly
<anholt>
tintou: at that point I think you're stuck with "expose support for gl texcoord, do your own allocation of texcoord to unused varying slots at backend codegen time"
<jenatali>
FWIW that's what I did recently
<alyssa>
on the other hand, only the drivers that set internal=true care about the value
<anholt>
rbed, should probably give others a chance to look, though :)
frieder has quit [Ping timeout: 480 seconds]
<alyssa>
sure, thanks :)
<alyssa>
I think the only behaviour change is whether NIR_PRINT=1 prints meta shaders for e.g. v3dv
<zmike>
(NIR_DEBUG=print)
<alyssa>
tells you how often i use it
<anholt>
tintou: we could also maybe do something with using texcoord declarations (or not) in linked shaders to skip/reduce the location fixup in the common case. dunno.
<jenatali>
Yeah, unless people added new dependencies on internal vs not
<alyssa>
zmike: I always do {ISA}_MESA_DEBUG=shaders which dumps optimized NIR and backend IR and disassembly
<jenatali>
I added that to be able to print CL shaders without dumping all of libclc, which is an insane amount of code...
<alyssa>
don't usually care about pass-by-pass NIR dumps
<alyssa>
jenatali: We check it in panfrost
<jenatali>
Ah cool :)
<alyssa>
the compute shader used for indirect draws is massive, for ex
<alyssa>
BIFROST_MESA_DEBUG=shaders won't dump it
<alyssa>
BIFROST_MESA_DEBUG=shaders,internal will
* alyssa
tries to run deqp-vk
<alyssa>
I suppose LIBGL_DRIVERS_PATH doesn't work
<anholt>
I hear meson devenv -C build is supposed to help now.
<alyssa>
VK_ICD_FILENAMES=~/mesa/build/src/panfrost/vulkan/panfrost_devenv_icd.aarch64.json gets further
<cheako>
Testing today and semaphore caching makes no differance. I'm moving on to caching imageviews, with a goal at caching the whole image stack eventually.
<alyssa>
oh right this one is 100% my fault
jhli has joined #dri-devel
rpigott has joined #dri-devel
ybogdano has joined #dri-devel
<shadeslayer>
<anholt> "I hear meson devenv -C build..." <- Oh nice, didn't know about that one
ngcortes has quit [Read error: Connection reset by peer]
mattst88 has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
gouchi has joined #dri-devel
mattst88 has joined #dri-devel
<sravn>
danvet: I think I used up my share of "asking the professor questions" in the fbcon series. Looks good. I skipped a few patches in the hope someone else will find time to dive into them
<danvet>
sravn, you mean anything from you I should review in return?
<sravn>
danvet: Hee, I am already behind processing feedback. dianders and pinchartl gave a lot of good feedback that I need to address. I am going to introduce a drm_bridge_helper in my re-spin of that series.
<sravn>
If someone came in and sweeped all the panel patches that would be good, but I think thats something for the weekend to take a peek at. They have piled up it seems
<danvet>
javierm, I'm prepping a new version of the series anyway, so pls look at that one
<javierm>
danvet: Ok, sorry for not reviewing yet but got distracted by other stuff
<danvet>
javierm, hey no worries, I've been like weeks late on average with my promised reviews
<danvet>
last few months :-/
turol has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
HdkR has joined #dri-devel
mattrope has joined #dri-devel
Plagman has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
romangg has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
milek7 has joined #dri-devel
<danvet>
sravn, hah I wont edit the TODO, because the olpc_dcon TODO in staging already explains that you should use drm self-refresh helpers here :-)
fahien has joined #dri-devel
maxzor has quit [Remote host closed the connection]
oneforall2 has quit [Quit: Leaving]
mceier has joined #dri-devel
jani has joined #dri-devel
Lynne has joined #dri-devel
oneforall2 has joined #dri-devel
<demarchi>
mlankhorst: could we have a drm-misc-next pull to drm-next before next week? I have some patches to land on drm-intel-next that depend some merged in drm-misc-next
vsyrjala has joined #dri-devel
<demarchi>
and next week airlied plans to backmerge rc4 and that could go to drm-intel-next
ngcortes has quit [Ping timeout: 480 seconds]
<anholt>
zmike: is there a more limited subset of piglit that might cover what you need for the no-timelines knob?
<zmike>
anholt: not really? the point is just to run everything to make sure I didn't break vk 1.0 support in some subtle way
<anholt>
ok. given the name I was thinking maybe there was just something fence-related we could target.
<zmike>
sadly not
<zmike>
it ends up affecting pretty much the whole driver
danvet has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
lkw has quit [Quit: leaving]
cleverca22[m] has joined #dri-devel
<anholt>
oh no. I forgot to add prefix support to piglit. guess we're going to have to have a total of 2 ci jobs for zink until I sort that out.
gawin has quit [Ping timeout: 480 seconds]
nchery has quit [Remote host closed the connection]
chema has joined #dri-devel
nchery has joined #dri-devel
rodrigovivi is now known as vivijim
Duke`` has quit [Ping timeout: 480 seconds]
vivijim is now known as rodrigovivi
MatrixTravelerbot[m] has joined #dri-devel
DrNick has joined #dri-devel
DrNick is now known as Guest15
heftig has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
gawin has joined #dri-devel
bylaws has joined #dri-devel
ella-0[m] has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<jenatali>
If I have a GL texture, write to it on one context on one thread, and read from it on another context on another thread... is that well-defined?
<jenatali>
I'm realizing our driver has some state that's global per-resource, but needs to be per-context per-resource
<jekstrand>
You might need a glFlush() in there. Not sure.
* jekstrand
isn't a GL expert
<jekstrand>
Kayden: ^^
<zmike>
yes, we had issues with that last year during the conversion to async gallium flushing
<zmike>
the flush guarantees that only one context is truly active at a time
<jenatali>
I see
tomba has joined #dri-devel
<jenatali>
I don't suppose you have any spec wording on that somewhere?
mvlad has quit [Remote host closed the connection]
<zmike>
you could probably find it if you looked through git log to find when async flushes got reverted
<zmike>
we all had to put on our big brain hats that day
<jenatali>
I assume that mesa/main or mesa/st doesn't insert context flushes automatically when tracking these hazards, right? :)
<jenatali>
Just debating if I should try to implicitly synchronize multiple contexts in my backend (like I do in our 11on12 layer for graphics+video) or if I should just assume someone else is going to at least flush them in the right order
<anholt>
daniels: bummer. that didn't seem to do it, but maybe I need to figure out how to invoke qemu on my own without bothering gitlab about it.