08:58 mlankhorst: drm-misc-next-fixes is now open
09:08 pq: silurian_invader, if that's about dumb buffers, they are not meant to be used for texturing either. They are meant only for CPU writes and display controller scans out. Any other case might as well (even randomly!) not work or be unusably slow.
15:47 silurian_invader: pq: well, it works and that's what I get from X...
15:50 pq: silurian_invader, what do you mean you get a dumb buffer from X? What is "you"?
15:51 silurian_invader: library implementing "software" (opengl) cursor support
15:51 pq: It *can* work, sometimes, on some platforms, but you cannot rely on dumb buffers being accessible to the GPU.
15:51 silurian_invader: the cursor is created as a dumb bo since X has no idea it's going to end up as a texture
15:51 pq: How does it end up as a texture?
15:51 silurian_invader: it works on my platform, and I don't really care too much about portability because most other platforms have real cursor planes
15:52 silurian_invader: EGL_LINUX_DMA_BUF_EXT
15:52 silurian_invader: if the GPU can't handle the BO then the import will fail
15:53 silurian_invader: on this platform the only way this can happen is funny things with the iommu, so I am not worried
15:53 pq: X is pushing dunb buffers to KMS, so how does it end up as a texture? Is this about virtualization?
15:53 silurian_invader: > library implementing "software" (opengl) cursor support
15:53 pq: I've no idea what that means or where it sits
15:54 pq: is it an Xorg module?
15:54 silurian_invader: it probably should be, but it's a LD_PRELOAD library to reimplement drmModeSetCursor et al.
15:55 pq: oh, that level of hacky, ok
15:55 silurian_invader: yeah; I'm mostly interested in it as a proof of concept
15:55 silurian_invader: and then maybe I will come back and do things correctly
15:56 pq: What's wrong with Xorg's own software cursor?
15:56 silurian_invader: performance
15:56 silurian_invader: it drops the FPS by around half when you wiggle it over anything GPU accelerated
15:57 pq: Why are you able to do better, just curious?
15:57 silurian_invader: the crtc has another plane that we can use for the cursor
15:58 pq: didn't you say software cursor via opengl?
15:58 silurian_invader: yes
15:58 pq: why opengl if you have a spare KMS plane for it?
15:59 silurian_invader: the plane is fullscreen and non-resizable
15:59 pq: ooh
15:59 silurian_invader: and the existing library I am working off uses opengl for blitting so hey, I might as well
15:59 pq: heh
15:59 silurian_invader: it would probably be possible to use swcursor on the second plane
16:00 silurian_invader: which might not be too bad considering the cursor is only 64x64
16:01 pq: I'm still somewhat puzzled why all that is more performant than Xorg's own software cursor. Do you not have Glamor going on your platform?
16:01 silurian_invader: yes, I have glamor