<tzimmermann>
javierm, that issue was reported, but it don't remember about patches. last time this was related to nvidia.ko, so priority was low. meanwhile nvidia had some patches for a console somewhere
srslypascal has joined #dri-devel
<javierm>
tzimmermann: ah, I'm misremembering then
frieder has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
ice9 has joined #dri-devel
ice9 has quit [Read error: Connection reset by peer]
<eric_engestrom>
Venemo: I didn't know about the PLT until I read that issue, but your guess of that "lazy binding" being related to the weak symbols that we use is reasonable
<Venemo>
I spent some time googling but I couldn't find a satisfactory explanation anywhere
jkrzyszt has joined #dri-devel
lemonzest has joined #dri-devel
rasterman has joined #dri-devel
mohamexiety has joined #dri-devel
kts has joined #dri-devel
kts has quit []
yuq825 has left #dri-devel [#dri-devel]
<javierm>
tzimmermann: so you were right from the answer, it happens with the nvidia driver and the problem is that is relying on efifb/simpledrm
<tzimmermann>
javierm, you told me what happened there: somehow one instance of the driver killed the efifb that was used by the other instance IIRC
<javierm>
tzimmermann: yeah, I remember now
kts has joined #dri-devel
junaid has quit [Remote host closed the connection]
<tzimmermann>
i remenber now. several of the cleanup patches had regressions, so the patchset didn't make it yet
frytaped is now known as godvino
<javierm>
tzimmermann: yeah and since is nvidia's fault to not set up their own emulated fbdev it was considered not worth the effort to keep pushing that series
tobiasjakobi has joined #dri-devel
godvino has quit [Quit: WeeChat 3.6]
frytaped has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<DemiMarie>
airlied: thanks for the link, it looks like it might be somewhat usable for Qubes.
<DemiMarie>
jenatali: so the context is that Qubes OS wants to be able to get at the contents of each window, but that requires writing a full WDDM driver (as opposed to a display-only driver) and so far the cost of that has been prohibitive.
mohamed has joined #dri-devel
mohamexiety has quit [Ping timeout: 480 seconds]
mohamed has quit []
shsharma_ is now known as shashanks
agd5f_ has joined #dri-devel
fxkamd has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
jdavies has joined #dri-devel
jdavies is now known as Guest8325
agd5f_ has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
agd5f_ has joined #dri-devel
Guest8325 has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
mbrost has joined #dri-devel
bgs has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
Zopolis4 has quit []
maxzor has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
greenjustin has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
godvino has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
fxkamd has quit []
<eric_engestrom>
kusma, DavidHeidelberg[m]: for the MR splitting the docs out of the main .gitlab-ci.yml, should we just re-assign it to marge, or is there something else that should be done first?
<eric_engestrom>
^ my bad, I missed that it's already re-assigned
stuarts has joined #dri-devel
kzd has joined #dri-devel
devilhorns has quit []
fab has quit [Quit: fab]
fab has joined #dri-devel
<DavidHeidelberg[m]>
eric_engestrom np, it was passing but one gitlab job didn't got to the runners..
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
agneli has quit [Remote host closed the connection]
fab has quit [Quit: fab]
devilhorns has joined #dri-devel
agd5f_ has joined #dri-devel
agneli has joined #dri-devel
bluetail3 has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
Haaninjo has joined #dri-devel
<jenatali>
Demi: I'm so confused as to what Qubes has to do with Windows/WDDM
rosefromthedead has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
<DemiMarie>
jenatali: Qubes has support for Windows, but the current Windows tools don’t have good GUI integration.
<jenatali>
lina: "In Vulkan, there is no explicit synchronization of buffers." I think you meant implicit?
mivanchev has joined #dri-devel
<mivanchev>
Mesa folks! Just stopping by to self-promote my newest addition to https://github.com/MIvanchev/static-wine32: a fully static Vulkan loader and Mesa Vulkan drivers :D
<mivanchev>
I was very nice experience making it happen and LTO gives us more than just confidence
<lina>
jenatali: Whoops, thanks! Fixed (once CI runs)!
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<jenatali>
Good read. I'm super interested in this space because WDDM is all explicit sync. Except we don't have a way of tying together a buffer and fence, the fence needs to be marshaled separately from the buffer :(
tursulin has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
frieder has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
mivanchev: nice, btw. we originally kept patches against the wine for gallium-nine, there is chances these days, we could integrate nine into d3d9 layer again (seems like wine people are willing to talk about it)
<DavidHeidelberg[m]>
*chance
alyssa has quit [Quit: leaving]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
djbw has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest8353
rsalvaterra_ is now known as rsalvaterra
kts has quit [Quit: Leaving]
ybogdano is now known as Guest8355
ybogdano has joined #dri-devel
Guest8354 has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<ngcortes>
NB: Intel Mesa CI will be down momentarily for an automation update. We'll let everyone know when it's back online.
tobiasjakobi has quit []
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
<DemiMarie>
jenatali: yeah, right now the support for Windows guests is not very good
<jenatali>
Anybody (gfxstrand) have opinions on doing a native surface -> vk surface map in the vk instance?
Cyrinux9 has quit []
Cyrinux9 has joined #dri-devel
<jenatali>
Looks like some apps like to create/leak surface objects for a single native surface, and we can't really support multiple vk surface objects (that actually get used for swapchains) bound to the same native surface
shashanks has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
jkrzyszt has joined #dri-devel
Leopold__ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
agd5f_ has joined #dri-devel
ioldoortileotm^ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
mohamexiety has joined #dri-devel
gouchi has joined #dri-devel
sghuge has joined #dri-devel
<gfxstrand>
robclark: Ok, I think I may be missing something.
<gfxstrand>
robclark: What's the behavior when no deadline is set? Does no deadline mean ASAP or "whenever you get to it"?
Leopold__ has quit [Remote host closed the connection]
<robclark>
no deadline set means "same as current behavior, ie. driver that created the fence doesn't get any deadline hint
<gfxstrand>
Ok...
<robclark>
for i915, that would mean no rps boost... which is current bhavior
<gfxstrand>
Right
<robclark>
basically it was way to opt-in
<robclark>
and.. if you are doing some "housekeeping wait" in userspace, you don't want to use deadline
<robclark>
(like waiting to clean up after some gpu work)
Leopold_ has joined #dri-devel
<gfxstrand>
Okay
<gfxstrand>
So it's not the same as an immedate deadline or an infinite deadline?
<gfxstrand>
It's a secret third thing?
Duke`` has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
<robclark>
gfxstrand: yeah, I guess it would amount to a secret thrid thing.. and actually kinda worse because I suppose a lame driver implementation could ignore the deadline and boost just because there is a deadline
mbrost_ has quit [Ping timeout: 480 seconds]
<robclark>
(like my implementation of it for drm/i915... although I expect that patch to be replaced by someone who actually knows their way around i915)
maxzor has quit []
<gfxstrand>
robclark: And we want vkCmdWaitForFences etc. to have a deadline of ASAP because userspace is waiting? I guess that makes sense.
<robclark>
I think so.. for same reason glFinish() did back in the day :-P
<robclark>
could make sense to have extension to expose that decision to the app
<robclark>
but first step is get kernel part in place ;-)
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
<gfxstrand>
robclark: So, what userspace is exercising the part where we have interesting deadlines?
<gfxstrand>
robclark: Or is that happening through KMS automatically?
<robclark>
there is some automatic kms deadline setting happening.. assuming compositor isn't sophisticated enough to be waiting for fence to signal in userspace (in which case compositor would need to use the SET_DEADLINE ioctl)
<robclark>
inside a vk or gl driver, we really only have choice between "gimme ASAP" and "no deadline"
<robclark>
tho it could be interesting to expose that via some sort of extension
<gfxstrand>
Yeah
<robclark>
fwiw, there is some intel gitlab issue about this, which I'm completely failing to find atm.. basically clvk was slower than native cl just because it was doing vkCmdWaitForFences() but native cl was doing I915_GEM_WAIT
<robclark>
the later boosts freq, the former does not (before my MR+patchset)
<robclark>
technically for that we don't need deadline.. just a pls make go fast flag... but deadlines are useful when you have things like vsync.. and I figured we could kill two stones with one bird.. or something along those lines :-P
<gfxstrand>
Yeah
<gfxstrand>
It certainly seems better than some of the other options
<gfxstrand>
It may also help v3dv. Have you talked to those folks?
<gfxstrand>
When I reworked the v3dv sync code, I fixed a bug in their WaitForFences implementation and now they need some sort of boost.
junaid has quit [Remote host closed the connection]
<robclark>
hmm, I have not talked to them specifically.. I assume someone follows dri-devel?
heat_ has joined #dri-devel
<clever>
ive been digging thru radeontop, and ran into GRBM_STATUS, as best as i can tell, its a bitfield representing what hw blocks are in use?
<clever>
and to get a usage%, your only option is to poll it at a relatively high rate, and measure it yourself?
heat has quit [Read error: No route to host]
<gfxstrand>
robclark: probably. IDK if they're paying attention to this particular thing.
<robclark>
hmm, I'm not even seeing devfreq or anything like that on kernel side for v3d..
<clever>
robclark: v3d runs off the CM_V3DDIV/CM_V3DCTL divider
<clever>
and i'm not sure where the freq limits are defined, linux might only use this for on/off control?
alarumbe has quit [Remote host closed the connection]
<robclark>
I'm just trying to see how boost/deadline hints would fit in with v3d... but I guess that would require the CPU to be directing the fw somewhere..
<robclark>
(for a6xx we aren't really controlling the freq directly, but just tellin gthe fw what to do
<gfxstrand>
Yeah
<gfxstrand>
In this particular case, they were spinning in userspace or waking up every so often and it was causing things to CPU boost.
<gfxstrand>
It was all ver indirect but it lead to a perf regression.
<robclark>
_ahh_.. good 'ol spacebar heater ;-)
<gfxstrand>
Yup
<gfxstrand>
At least with deadlines they maybe have "correct" way to do it.
<clever>
robclark: the v3d is fairly dumb, and i would say it lacks firmware, you just generate a control list that can render a frame, and then the hw just steps thru the bytecode and runs shaders as directed
<clever>
robclark: the smartest thing ive found in that area, is that you can put the control list into a ringbuffer, and if the hw hits the end (your write ptr) it will PAUSE, and can automatically resume when you append (update the end/write ptr)
<clever>
so you can just blindly append jobs to the ring, and not have to deal with race conditions
<robclark>
but if something fw is controlling the freq, I guess fw is doing some sort of utilization based governor?
alarumbe has joined #dri-devel
<clever>
yeah, when using the official firmware, the VPU (a dual core cpu) manages the v3d clock, v3d power, and many other things
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
<clever>
but thats mostly been down-graded purely to a throttling manager
<clever>
in the event of overheating or undervoltage, it will reduce various clocks, to prevent a crash
<robclark>
so, hurry-up-and-wait unless thermal/etc
<clever>
in the old days, the entire opengl stack ran on the VPU, and the linux side was just an RPC shim
<clever>
but mesa has since taken over that job, and linux is writing the control regs in v3d directly
gouchi has quit [Remote host closed the connection]
agd5f_ has quit [Ping timeout: 480 seconds]
alarumbe has quit []
Haaninjo has quit [Quit: Ex-Chat]
<robclark>
mareko: I guess PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION and PIPE_CAP_MAP_UNSYNCHRONIZED_THREAD_SAFE don't really imply any more than what is already needed for TC?
ice9 has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
alarumbe has joined #dri-devel
<clever>
robclark: another complication, is that CM_V3DDIV is just dividing down from one of the PLL taps, *looks*
<clever>
V3D is in the core muxes group, and can pull from plla, pllc, plld or pllh
<clever>
but it can only get something that is an integer fraction of those, i think
<robclark>
As long as there is more than one possible freq, there is a choice to make ;-)
<clever>
yep
<clever>
some of these clock blocks support fractional division
<clever>
where it basically just alternates between /5 and /6
<clever>
so the average clock is somewhere between the 2
nchery is now known as Guest8366
nchery has joined #dri-devel
<clever>
but that means some of the clocks can be as short as /5, and you still need to keep things within the rise-time and propagation limits
danvet has quit [Ping timeout: 480 seconds]
ice9 has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
sghuge_ has joined #dri-devel
<DavidHeidelberg[m]>
NOTE NOTE: If you get stuck pipeline on specific job, GitLab doesn't sent TIME to TIME the job to the runner. HOW TO: If you notice this type of stall in Marge queue, just re-trigger any finished job on the same runner group, then GitLab flush the job and send it to both runners !!! <-
sghuge has quit [Quit: Leaving]
smiles_1111 has joined #dri-devel
sghuge_ has left #dri-devel [#dri-devel]
sghuge has joined #dri-devel
<zmike>
robclark: I think those are glthread, aren't they?
<zmike>
for the subdata optimization
rasterman has quit [Quit: Gettin' stinky!]
pcercuei has quit [Quit: dodo]
binhani has joined #dri-devel
<binhani>
robclark: last Saturday I was asking about adriconf enhancements project listed on GSoC and you told me that the Wiki needed updating in general. With that said, can you help me get on track with up-to-date projects for this GSoC