ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
kts has quit [Quit: Konversation terminated!]
dreda has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
srslypascal has joined #dri-devel
slattann has joined #dri-devel
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
numerator has quit []
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
mclasen has quit [Ping timeout: 480 seconds]
<mareko>
has gitlab just changed its style?
<vyivel>
gitlab.fd.o was updated recentry afaiu so there are some visual changes
Daanct12 has joined #dri-devel
aravind has joined #dri-devel
bmodem has joined #dri-devel
itoral has joined #dri-devel
itoral_ has joined #dri-devel
bmodem1 has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
slattann1 has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
bmodem has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
bmodem1 has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
bmodem has joined #dri-devel
itoral_ has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
alatiera0 has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
rgallaispou has joined #dri-devel
rasterman has joined #dri-devel
luc has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<luc>
hi, I recently read the Mesa stream output part, I noticed the comment on `pipe_stream_output_info.stride[PIPE_MAX_SO_BUFFERS]` (p_state.h:267) which says "stride for an entire vertex for each buffer in dwords", so why "in dwords" that means 8 bytes in general? is there something imperative that requires this?
bmodem has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<airlied>
luc: dwords means 4 byts
luc has quit [Quit: Page closed]
luc has joined #dri-devel
bmodem has joined #dri-devel
pcercuei has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
tursulin has joined #dri-devel
<ElementW>
airlied: This raises the question as to why Mesa uses x86-centric wording in arch-agnostic or even non-x86 code... A "word" on ARM is 32 bits for example, so it makes no sense in that context if you want to refer to a 4-byte int
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
RSpliet has quit [Read error: Connection reset by peer]
RSpliet has joined #dri-devel
<ishitatsuyuki>
because gpus are 32bit-centric archs
<ishitatsuyuki>
imo
kts has quit [Quit: Konversation terminated!]
<ishitatsuyuki>
well, nvm that was irrelevant
<ishitatsuyuki>
I think dword is pretty much a convention from the old ages at this point, and it's defined *as* 32-bit integer, not the double of whatever "word"
YuGiOhJCJ has joined #dri-devel
mclasen has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
srslypascal has quit []
srslypascal has joined #dri-devel
<ElementW>
ishitatsuyuki: I see that, but in my opinion it's confusing to anybody who hasn't seen x86 specific code before, and the name "word" is wholly unexpressive about what the actual size is going to be, compared to <stdint.h> types like uint32_t
<ishitatsuyuki>
idk, you literally see it everywhere especially if you're exposed to Win32
<ElementW>
Win32 is the reason this garbage persists
<ElementW>
I don't see why and how we should respect that
<ishitatsuyuki>
so? what alternative do you suggest?
apinheiro has joined #dri-devel
<ElementW>
word/dword/qword can persist in x86 related code just fine, e.g. Intel drivers; and maybe can also be used in some specific contexts where a word refers to the GPU native word size
<ElementW>
Anywhere else though IMO should be <stdint.h> types, or native C types if applicable (because of per-platform length differences)
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<ishitatsuyuki>
the code in question is written 11 years ago, and I don't see how trying to change all of this is productive
<ishitatsuyuki>
you're welcomed to raise suggestions about that for future MRs, as well as adopting the convention in code you write, but there's no value in mass-renaming things for something that can be learnt through a single ask on IRC
<ElementW>
Having to ask what word means on IRC means the code isn't clear to begin with
itoral has quit [Read error: Connection reset by peer]
<ElementW>
I think it's particularly egregious in the case of codebases that run across a variety of platforms like Mesa, where a potential difference in what a "word" is can be important
<ElementW>
Just because it's commonly defined as 16-bit because of x86 legacy doesn't mean it's going to be the same everywhere
bmodem has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
I don't see how this discussion can lead to a productive outcome
rkanwal has joined #dri-devel
<ElementW>
IDK maybe you all are infailible humans that would never confuse "word" as x86 legacy and "word" on RISC-V (where 32-bit load/store instructions are called LW and SW)
<ElementW>
This perceived lack of "productive outcome" is how you end up with wholly unpaltable code years down the line, simply because no immediate benefit could be figured out
<ElementW>
the entirety of Win32 is the perfect example of that
<ElementW>
(though I understand Win32's staleness is for compatibility reasons)
elongbug has joined #dri-devel
<pq>
I think we got your opinion, and it doesn't seem anyone disagrees.
<ElementW>
I'm not saying "word" being in the codebase is sacrilegious, just that it's unclear at best
<pcercuei>
Just replace it everywhere
<pcercuei>
"u32 word", "u16 word" would make much more sense
<ElementW>
pcercuei: Not that simple, there are plenty of legitimate places, like Intel drivers, or Gallium Nine
<pcercuei>
ElementW: aren't we getting discrete Intel cards soon?
<ElementW>
But for example I don't really get why virgl refers to it; is virgl x86(-64) only?
<pcercuei>
We'll be running those on arm64 before you know it
<pcercuei>
Also it wouldn't hurt to add more clarification even in those "legitimate places" IMHO
<ElementW>
Discrete Intel stuff should use explicit types yep, unless the card architecture has its "word" defined as 16-bit then OK maybe
bmodem has joined #dri-devel
<ElementW>
pcercuei: Jeff Geerling's attempt at running all things PCI-e on a Raspberry Pi 4 Compute Module is the beginning of that
<ElementW>
I know he's had trouble compiling and running drivers of many cards over the years, and I wouldn't be surprised if he had to hack a few #defines around to make WORD/DWORD-using code happy
<ElementW>
Especially since I don't see Mesa #defining or typedef'ing WORD/DWORD anywhere
<ElementW>
And then you have "funny" things like util/bitscan.h's u_foreach_bit macro saying "uint32_t __dword", when at the same time u_foreach_bit64 says "uint64_t __dword"
<ElementW>
If that isn't confusing idk what it is
bmodem has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<ElementW>
Unrelatedly is the only way to obtain per-process graphics resource accounting info through fdinfo of the render/control node fd's?
rkanwal has quit [Quit: rkanwal]
<Kayden>
I think uint64_t __dword was just a copy and paste mistake when making a 64-bit version of the macro
<Kayden>
patches welcome to fix that
Company has joined #dri-devel
kchibisov has quit [Read error: Connection reset by peer]
devilhorns has joined #dri-devel
<Kayden>
re intel GPUs, yes, the card architecture defines Word as 16-bit, DWord as 32-bit, QWord as 64-bit, OWord (octo-word!) as 128-bit, and HWord (hexa-word!) as 256-bit, and the shader register types, shader messages, all use those. also the state packets are focused around DWords (32-bit) and various commands are "write dword/write qword"
kchibisov has joined #dri-devel
<Kayden>
which...yeah, confusing, especially on a host CPU that doesn't follow that convention
<Kayden>
definitely a fan of uint*_t types that actually have an obvious meaning
rkanwal has joined #dri-devel
kts has joined #dri-devel
bmodem has joined #dri-devel
Peste_Bubonica has joined #dri-devel
<frankbinns>
Marge Bot failed with "I couldn't merge this branch: Failed to push rebased changes, check my logs!"
<frankbinns>
Does anyone know how I can check the logs?
<jasuarez>
in my case the error is different: "Something seems broken on my local git repo; check my logs!"
<jasuarez>
seems it is retrying every minute
<enunes>
I am getting intermittent "Permission denied" "Could not read from remote repository" in some attempts to fetch from gitlab.freedesktop.org today, maybe Marge is hitting the same
icecream95 has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
alyssa has joined #dri-devel
srslypascal has joined #dri-devel
<alyssa>
So we now have 5 incompatible copies of GenXML in the tree
<alyssa>
admittedly that's mostly fault
<alyssa>
maybe time to revisit whether a common GenXML makes sense?
<alyssa>
the different flavours of GenXML are slightly incompatible, but at least the v3d/panfrost/agx flavours are pretty close
bbrezillon has quit [Ping timeout: 480 seconds]
bbrezillon has joined #dri-devel
<alyssa>
MTCoster: ^^ was newly thinking about this given your recent MR
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
<MTCoster>
alyssa: I wouldn't mind taking a crack at this after-hours if the result is likely to be accepted in principal. I ran into so many "limitations" in our flavour that seem to just be artefacts of the repeated copy-paste-edit cycle, so it would be nice to clean things up a bit in that regard
aravind has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
<alyssa>
MTCoster: *nod*
<alyssa>
curious where the intel and v3d people are at
<MTCoster>
Semi-related, it would be nice to raise the minimum python version - most supported LTS distros seem to have at least 3.7 (Ubuntu 18.04, Debian Stretch is EOL this month so Buster, Fedora 26)
<alyssa>
Seems reasonable
bmodem has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
technopoirot has joined #dri-devel
technopo1rot has joined #dri-devel
srslypascal has joined #dri-devel
Duke`` has joined #dri-devel
sdutt has joined #dri-devel
<mripard>
what's the expectation wrt merging patches in igt? The same than in DRM (as soon as I get a review, merge the patches) ?
<emersion>
yea (and leave a bit of time, e.g. days, between the email gets sent and the patch gets merged, so that someone with objections has time to comment)
<zackr>
danvet: how would having something else than a cursor in a cursor plane break? whatever is in there will be rendered at crtc_x|crtc_y. as long as as it's not bigger than DRM_CAP_CURSOR_WIDTH|DRM_CAP_CURSOR_HEIGHT it shouldn't matter. so where's the break?
bmodem has joined #dri-devel
<emersion>
do you not use the host's cursor at all?
<emersion>
how does the VM software show the cursor image on screen?
<mripard>
emersion: thanks :)
<mripard>
it's been monthes, so I think I left a bit of time already :)
<zackr>
that depends on a lot of things? is is a gaming mouse? then the cursor is locked in the vm, rendered inside. is it a seamless cursor? then the exact cursor image is rendered by the host at guest's crtc_x|crtc_y
tales-aparecida_ has joined #dri-devel
tales-aparecida_ has quit [Remote host closed the connection]
<emersion>
"rendered by the host at guest's crtc_x|crtc_y" → by who?
<emersion>
is the X11/Wayland cursor used?
<zackr>
the image of the cursor plane is used as the host side cursor
<zackr>
so by whatever ws is running on the given host
<emersion>
ok, so the guest's image is passed up to the WSI, correct?
<pq>
if it's used the host side cursor, then it's position is usually not guest crtc_x,crtc_y
<emersion>
to the host's WSI
<zackr>
correct
<emersion>
then it's not positioned at CRTC_X/Y
<emersion>
and that breaks stuff
<zackr>
i'm still not seeing it, what breaks?
<pq>
because the image that guest put on the cursor plane will be moving along with the host side pointer device
<pq>
that's completely unexpected
<zackr>
the host side cursor will be offset to match what the guest wants
<zackr>
the size of the host side cursor doesn't have to match the drm cursor plane
<zackr>
it can be larger (or smaller i guess)
<jekstrand>
airlied, danvet: I'm happy to do whatever. Though, I think for emersion's use-case, he'd really like something that doesn't require the DRM FD. Not sure we can get that, though.
<emersion>
jekstrand: i wouldn't mind opening a random DRM FD via libdrm
<jekstrand>
emersion: Ok, cool.
<emersion>
that doesnt require vulkan or GBM at least
<jekstrand>
For Vulkan WSI, I'm not sure a DRM cap is actually better than just testing, TBH. I don't think we get the DRM FD as part of wsi_init so we'd need to delay to swapchain time anyway.
<jekstrand>
Might be able to plumb it through if we tried, though.
<pq>
zackr, the thing that matters is that the host side cursor is moving with the host pointer device position, by definition. When guest cursor plane contains not-a-cursor, you do not want the not-a-cursor to move with the host pointer device.
<emersion>
zackr: even with an offset (which is hacky and would certainly result in weird stuff), that wouldn't be enough, because the host cursor moves on its own
<emersion>
guest configures a plane with X=200, VM passes it up to the host with an offset, then user moves the mouse and the cursor is painted somewhere else before the VM software has any say in it
<zackr>
pq: it's the guest that's "moving" the cursor. not the other way around. if the guest isn't setting the cursor position, then mouse moves won't move the host side cursor i.e. it will remain at whatever crtc_x|crtc_y guest set it to
<pq>
zackr, i tried my best to read the whole email thread, and I think everyone is lost in the weed. It would probably help to start from the top and explain which use cases you are considering there and how they are being fixed.
<zackr>
emersion: it doesn't. in seamless mode the host cursor disappears as it enters the guest window
<emersion>
so you don't use the host WSI after all?
<emersion>
and you get bad latency?
<emersion>
"bad" as explained in the old thread
<pq>
zackr, because all the replies from you in email, and here, seem to the talking about something else than anyone else thought of.
<zackr>
no, you don't disable it, you just let the guest the guest drive it
<zackr>
pq: that's because this has nothing to do with the patch =) this is a discussion that emersion wants to have but it's not related to the series
<zackr>
the series fixes a long standing problem with cursor clicks being routed to incorrect coordinates
<pq>
the only think I do see is that this is related to the patch series
<zackr>
the way virtualized driver handle cursor plane is orthogonal to that
<emersion>
you can't just slap the legacy uAPI hotspot into atomic KMS and be done with it
<emersion>
UNIVERSAL_PLANES makes it so the cursor is no different from other planes
<pq>
If the virtualized drivers were not intentionally incorrect in handling the cursor plane they expose, you wouldn't need hotspot information to begin with.
<alyssa>
is Marge ok?
konstantin has joined #dri-devel
<alyssa>
!15767 was assignd to Marge 12 hours, but ignored
<pq>
IMO the first step is to fix the bug in the virtualised drivers, and not give any special handling to the cursor plane at all. The second step is to figure out how to improve the usability (to avoid roundtrip to VM latency in moving the cursor)
<alyssa>
whereas my MR !16868 was assigned a few minutes ago and Marge is already working on it
<zackr>
emersion: which is not the case on virtualized driver. it's never been that way. the host side code requires hotspot info, i'm open to any suggestions on how to do that besides properties
<emersion>
zackr: i'm describing the uAPI here
<emersion>
ie, user-space expectations
<emersion>
any driver which breaks these assumptions is buggy
<zackr>
emersion: cool, what is it?
<pq>
zackr, the virtualized driver is breaking the KMS UAPI contract by handling the universal cursor plane with legacy KMS UAPI semantics.
<pq>
that can be fixed by first removing the special-case handling of the cursor plane in the driver, and then re-introducing it exactly like it was with the new properties and a way for userspace to tell the driver that "I know, this is a very special cursor plane, only usable cursors and nothing more".
alyssa has left #dri-devel [#dri-devel]
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
<pq>
With universal planes, the contract is that all planes behave roughly the same, sans how KMS properties describe them. There is no KMS propery currently saying that the cursor plane will be flying with some pointer device.
<zackr>
pq: that doesn't seem to work. removing cursor planes unless the client advertises support for new cursor plane will break current gnome-shell/kwin. so to support the zero users using weston on virtualized drivers, we'll break every single user using virtualized driver
<pq>
with universal planes, all planes are supposed to be equal, and userspace makes use of that by putting not-a-cursor images on cursor planes
<emersion>
zackr: that won't break mutter/kwin, since they have a deny-list
<pq>
zackr, what do you mean by "break" there?
<emersion>
it seems "break" would mean "fallback to software cursor"
<zackr>
emersion: but the legacy code is working on top of cursor planes. so we can't disable cursor planes all over because it will break legacyu
<emersion>
(ie, cursor rendered by muter/kwin in OpenGL)
<zackr>
emersion: kwin and gnome-shell fallback to legacy kms which will break
<emersion>
no, just disable cursor planes only on atomic
<emersion>
keep exposing the legacy cursor
<zackr>
ok, so now we have the cap and heuristic to see whether a client is using legacy or atomic kms
<emersion>
there's no heuristic to have
<emersion>
an atomic client will enable DRM_CLIENT_CAP_ATOMIC
<emersion>
(maybe UNIVERSAL_PLANES is the thing to check for, not ATOMIC, but ATOMIC enables UNIVERSAL_PLANES)
<pq>
why would legacy KMS without cursor plane break? AFAIK, Mutter has fallbacks for legacy cursor API not working.
<pq>
or does this "break" mean "still works, but with noticeable latency"?
<emersion>
pq: still works, but breaks fancy features like the one which opens one window on the host per window in the guest, afaiu
<pq>
that's a feature I don't understand at all to begin with how that is even possible
<emersion>
these fancy features should just get disabled when the compositor doesn't support reporting hotspot
<pq>
KMS doesn't get windows, it gets just few FBs at most
<emersion>
yeah, that doesn't make sense to me either
<emersion>
use something like RDP for this kind of stuff
<pq>
if there is an alternate protocol, when why involve KMS at all?
<pq>
*then
<emersion>
yeah… especially when it results in all kind of complexity and glitches
* zackr
is now confused as well
<pq>
zackr, as you can see, we are wildly confused about what we are even talking about. Maybe it would be best to re-start the email thread and explain all the different use cases that require the hotspot properties.
<zackr>
this would be easier if i had a testcase for what you're trying to fix
<pq>
and since it is intimately tied to the hotspot properties, also explain how it will help the driver to differentiate userspace that uses a cursor plane for only *the* cursor from userspace that uses cursor plane as just another universal plane.
<zackr>
it's easy to see what's broken on atomic without hotspot data, but i haven't seen a testcase that shows what break with the current approach
<pq>
zackr, weston with weston-simple-shm open and the real cursor hidden should be good example. Weston will put the simple-shm window onto cursor plane.
<emersion>
you mean simple-egl?
<pq>
no, simple-shm
<pq>
only shm buffers can go to cursor plane in weston
<emersion>
oh, so weston will copy the shm buffer into the DRM dumb buffer?
<pq>
because the cursor plane needs special cursor buffers and those always manually copied
<emersion>
that's interesting
<emersion>
we do exactly the opposite
<emersion>
in wlroots
<pq>
heh
<zackr>
pq: ah, cool, let me try that. can i just run it from a console?
<pq>
so wlroots never gets software cursor into cursor plane?
<emersion>
use GBM for the cursor, and only DMA-BUFs can go in there
<pq>
zackr, ideally yes, if you have logind-enabled distribution
<emersion>
software cursors get copied to the GBM BO
<emersion>
but a regular wl_shm buffer won't be able to use the cursor plane when the real cursor is hidden
<pq>
emersion, that sounds similar to weston then. I'm not sure Weston tries to put dmabuf onto cursor plane.
<pq>
oh?
<pq>
emersion, what's the difference between a regular wl_shm buffer and a wl_shm cursor buffer?
<emersion>
we have a special codepath for wl_surface.set_cursor which copies
<pq>
aha
<pq>
so you have "cursors are special" path
<pq>
zackr, getting the real cursor hidden might need tricks, maybe running weston-terminal and typing a bit into it
<zackr>
pq: k, i'll give it a try. so run weston-simple-shm, start weston-terminal and see what happens with the cursor?
<pq>
yeah - and don't let those two windows overlap
<pq>
also make sure you have that seamless mouse thing on
<pq>
maybe easiest to start weston-terminal first and launch weston-simple-shm by typing into it
ManMower has joined #dri-devel
<pq>
zackr, meet ManMower who has had first-hand experience with the problem you are trying to reproduce.
devilhorns has quit []
<pq>
I should have gone home a long time ago, so .o/
<ManMower>
I'll be just a second. I don't have a 100% recollection of how to do this but it shouldn't take me long
<ManMower>
ah ha
<ManMower>
zackr: so the trick is to have a client that makes a small enough shm buffer to end up on the cursor plane, as well as another client that hides the cursor (so weston will use the "cursor plane" for the shm client). easy way to do this for me is to run weston-simple-damage --width=64 --height=64 to get the shm client, and weston-simple-dmabuf-egl to get a client that removes the cursor.
<ManMower>
then just mouse over the dmabuf client and the damage client will jump to the cursor location
<ManMower>
I'm reproducing this using a vmware ESXi vm
<zackr>
ManMower: awesome, thanks. i have three hours of meetings coming up but i'll try to reproduce this tonight. so just weston-simple-damage --width=64 --height=64 followed by weston-simple-dmabuf-egl should be enough?
<zackr>
i'm assuming this would be broken on all virtualized drivers
devilhorns has joined #dri-devel
<ManMower>
zackr: yep, that'll do it
ybogdano has joined #dri-devel
<emersion>
danvet, jekstrand: hm so following up with that reply, maybe we coulkd have /something/dmabuf/zero which is a dummy zero-sized dmabuf not tied to any actual device?
<emersion>
just like /dev/zero but for dmabufs
<emersion>
i'm not even sure zero-sized dmabufs are actually allowed
<ManMower>
I suppose it'd be very hard to just make an open fd to /dev/zero be that? :)
anholt has quit [Read error: Connection reset by peer]
<ManMower>
(actually, /dev/null would make more sense)
<emersion>
i should've said /dev/null, not /dev/zero
<emersion>
:P
<ManMower>
:D
<emersion>
i think that';d be hard yes
<emersion>
the FD type wouldn't be the same
anholt has joined #dri-devel
<danvet>
emersion, gregkh already said you wont have ioctl on sysfs
<emersion>
that can be something else than sysfs
<danvet>
unless we do something truly horrible where a read() returns the fd # of a dma_buf we just installed :-)
<emersion>
eh :S
<danvet>
my take is still to just whack it in there
<emersion>
that's simpler
rgallaispou has quit []
bmodem has quit []
alyssa has joined #dri-devel
<alyssa>
do I need an ack for a patch adding to docs/relnotes/new_features.txt?
<danvet>
emersion, btw did you see my comments yesterday on the virtual cursor discussion?
<danvet>
do I need to jump into the thread?
<emersion>
danvet: on IRC? or on the ML?
<emersion>
i've seen on IRC, and yeah i agree (see discussion above)
<emersion>
(but not sure about PLANE_TYPE_VIRTUAL_CURSOR, but that's bikeshedding)
<emersion>
danvet, no need to jump into the thread again, Zack will do some more investigation
<emersion>
we'll see what they reply then
<danvet>
ah cool
<danvet>
and yeah I guess we can bikeshed the name, but assuming I got this right, then we need to hide these plans from userspace in the atomic world
<danvet>
zackr, wrt your "won't this break legacy cursor", that's why I suggested a new plane type
<danvet>
so that we can hide that plane from universal plane/atomic by default, but the legacy cursor code can still use it
<danvet>
exactly how "normal" cursor planes are hidden without universal planes enabled
<danvet>
zackr, also that part I think we should backport, so that these virtual drivers stop exposing cursor planes which break the kms plane contract
<emersion>
danvet, do we really need a new plane type though?
<emersion>
(^ bikeshedding part)
<danvet>
unless we want to paint the shed differently that's the way universal planes hiding works
<emersion>
can't it just be a regular cursor plane, only visible to atomic if the cap is enabled, with an internal "is virtual" flag in the kernel
<danvet>
which is kinda what we need
<danvet>
I mean you can also pain your shed differently
<emersion>
:P
<danvet>
but thus far we signalled "this is a bit a funny plane with special uapi semantics" with the type
<emersion>
okay, was wondering if that was purely bikeshedding or if there was another reason
kts has quit [Ping timeout: 480 seconds]
<danvet>
emersion, well it is a shed color choice, but I do think it fits better than some new flag with the existing sheds we have :-)
<danvet>
makes for a better color composition
<emersion>
okay, just seems a bit weird to have two types for cursor, but yeah it's more explicit i suppose
sdutt has quit []
sdutt has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
rkanwal has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
slattann1 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
technopo1rot has quit []
technopo1rot has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
srslypascal has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
norris has joined #dri-devel
Danct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
eukara has quit [Ping timeout: 480 seconds]
X512 has joined #dri-devel
kem has joined #dri-devel
devilhorns has quit []
<X512>
How to contact Mike Blumenkrantz?
<HdkR>
X512: Poking zmike
<alyssa>
X512: Say Zink is slow and CI is reliable
<X512>
zmike: It seems there are some race condition that cause calling kopper_present then swapchain->presents is not yet created.
<X512>
Problem is not reproduced if multitheading is disabled in Gallium.
<zmike>
so you're triggering a present before creating the displaytarget?
<zmike>
don't do that
ngcortes has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
deathmist has quit [Quit: WeeChat 3.5]
X512 has quit [Quit: Vision[]: i've been blurred!]
Haaninjo has quit [Quit: Ex-Chat]
danvet has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
icecream95 has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
srslypascal has joined #dri-devel
ngcortes has joined #dri-devel
pcercuei has quit [Quit: dodo]
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
robclark: Is !16136 (allowing HW y-flip) of any interest to you? I've heard rumors that qualcomm HW can do Y-flip natively.
ybogdano has joined #dri-devel
neonking has quit [Remote host closed the connection]
<HdkR>
jekstrand: Nouveau might want it as well?
<robclark>
jekstrand: hmm, I think it can do y-flip in the blitter.. maybe there is something I haven't run across because I haven't looked for it, but at least on earlier gens blob was defn doing similar y-flip lowering as mesa and adding gates to do something like that in hw rather than few extra shader instructions doesn't really seem like adreno's style
oneforall2 has quit [Remote host closed the connection]