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.
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.
If there are any other options I'm not aware of, I'm very much listening.
Rob.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
