Hey Rob,
On 2018-07-19 09:26, Tomasz Figa wrote:
On Thu, Jul 19, 2018 at 12:08 AM Robert Foss <robert.f...@collabora.com> wrote:
Hey Rob,
On 2018-07-18 15:30, Rob Herring wrote:
On Tue, Jul 17, 2018 at 4:33 AM Robert Foss <robert.f...@collabora.com> wrote:
This series implements kms_swrast support for the Android
platform. And since having to debug a null pointer dereference,
simplify that process for the next guy.
So is this working for you now?
I'm seeing page-flips happen in the logs, but have no graphical output on the
Qemu-based setup I'm using now.
When using virgl I'm seeing the same page-flipping in the logs, but no graphical
output.
As it stands now, any kernel must have the following ioctls flagged with
DRM_RENDER_ALLOW[1], which isn't the case in the mainline kernel.
DRM_IOCTL_MODE_CREATE_DUMB
DRM_IOCTL_MODE_MAP_DUMB
Ah, sorry. I should have mentioned this. We have discussed this issue
in the past, but to no further conclusion.
But as I recall, I thought the issue was also allowing import and
export of dumb buffers?
Yeah, it's a two-parter for any AOSP Treble build.
1) Allow dumb buffer ioctls fom render nodes
2) Support moving buffers across processes.
Wouldn't 2) be automatically solved by 1), since we should be able to
run drmPrimeHandleToFD for dumb buffers already?
I thought, perhaps wrongly that drmPrimeHandleToFD was only applicable to
dmabufs.
I think I've misunderstood the restrictions of dumb buffers, if they're
shareable across processes using drmPrimeHandleToFD then only 1) is in our way.
While it would be possible to open a non-render node to pass the
authentication check, this would still cause authentication issues
when the /dev/dri/cardX node needs to be opened as master by both mesa
and the compositor.
Right. We've pretty much stripped the support that was there out. Plus
I don't think it will work with Treble.
I don't know how acceptable this series is for upstreaming, while relying on
a non-mainline kernel. I think the policy is to not accept changes that
don't have both a user and kernel space solution in place.
Like I noted yesterday[2] the alternative to using dumb buffers and having
authentication issues is using VGEM, which is new territory to me, and it would
take me a little bit of time to figure exactly how it fits into the current
kms_swrast approach.
Input, like noted before, is very much welcome.
I'm very much in favor of the former approach. VGEM seems like an
overly complicated solution when there's a very simple solution.
The former solution being what we have now, dumb buffers?
I don't think dumb buffers are a viable path due to 2) listed above.
I don't understand what 2) is about. Could you elaborate on it?
See above!
I'd personally be for dropping those strange restrictions from render
nodes. I don't see why a render node couldn't allocate and map a dumb
buffer (for software rendering) and share it with another process that
opened a control node (to display it).
From my understanding the wider communitys idea is to minimize the use of dumb
buffers.
A part of not allowing render nodes to use map dumb buffers is meant to
incentivize proprietary drivers to not do the simplest thing that could possibly
work, as far as I understand.
So while I'm happy to push that change upstream, if for no other reason than to
generate a dialogue, maybe it's not all that likely that it will be accepted.
If there are any other options I'm not aware of, I'm very much listening.
One could just call mmap() on DMA-buf FDs directly rather than
importing them, but that could open another can of worms, because FDs
don't give us any way to deduplicate buffers (you might be given
several FDs pointing to the same buffer, which in case of importing to
DRM would end up with the same GEM handle every time).
So mmap()ing dmabuf FDs dealing with that can of worms is preferable to looking
into a VGEM based approach?
Rob Herring, presumably rightly, seems to think going down the VGEM route is
opening a pretty bad can of worms too.
Rob.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
