From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: Rob Clark <robdclark@gmail.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: GEM allocation for para-virtualized DRM driver
Date: Mon, 20 Mar 2017 20:01:35 +0200 [thread overview]
Message-ID: <93a21d4e-8fcf-fa84-db68-738fcc294950@gmail.com> (raw)
In-Reply-To: <CAF6AEGuF5C9KWjEqw=G2=6ki+hf+h5Dfxa3ya0QAHMiFTWo_zQ@mail.gmail.com>
On 03/20/2017 07:38 PM, Rob Clark wrote:
> On Mon, Mar 20, 2017 at 1:18 PM, Oleksandr Andrushchenko
> <andr2000@gmail.com> wrote:
>>
>> On 03/18/2017 02:22 PM, Rob Clark wrote:
>>> On Fri, Mar 17, 2017 at 1:39 PM, Oleksandr Andrushchenko
>>> <andr2000@gmail.com> wrote:
>>>> Hello,
>>>> I am writing a para-virtualized DRM driver for Xen hypervisor
>>>> and it now works with DRM CMA helpers, but I would also like
>>>> to make it work with non-contigous memory: virtual machine
>>>> that the driver runs in can't guarantee that CMA is actually
>>>> physically contigous (that is not a problem because of IPMMU
>>>> and other means, the only constraint I have is that I cannot mmap
>>>> with pgprot == noncached). So, I am planning to use *drm_gem_get_pages* +
>>>> *shmem_read_mapping_page_gfp* to allocate memory for GEM objects
>>>> (scanout buffers + dma-bufs shared with virtual GPU)
>>>>
>>>> Do you think this is the right approach to take?
>>> I guess if you had some case where you needed to "migrate" buffers
>>> between host and guest memory, then TTM might be useful. Otherwise
>>> this sounds like the right approach.
>> Tried that today (drm_gem_get_pages), the result is interesting:
>>
>> 1. modetest
>> 1.1. Runs, I can see page flips
>> 1.2. vm_operations_struct.fault is called, I can vm_insert_page
>>
>> 2. kmscube (Rob, thanks for that :) + PowerVR SGX 6250
>> 2.1. Cannot initialize EGL
>> 2.2. vm_operations_struct.fault is NOT called
> jfwiw, pages will only get faulted in when CPU accesses them..
indeed, good catch
> modetest "renders" the frame on the CPU but kmscube does it on gpu.
yes, I have already learned that modetest only renders once and
then just flips
> So not seeing vm_operations_struct.fault is normal. The EGL fail is
> not..
>
>> In both cases 2 dumbs are created and successfully mmaped,
>> in case of kmscube there are also handle_to_fd IOCTLs issued
>> and no DRM errors observed. No DMA-BUF mmap attempt seen
>>
>> I re-checked 2) with alloc_pages + remap_pfn_range and it works
>> (it cannot unmap cleanly, but it could be because I didn't call
>> split_pages after alloc_pages), thus the setup is still good
>>
>> Can it be that the buffer allocated with drm_gem_get_pages
>> doesn't suit PowerVR for some reason?
> I've no idea what the state of things is w/ pvr as far as gbm support
> (not required/used by modetest, but anything that uses the gpu on
> "bare metal" needs it). Or what the state of dmabuf-import is with
> pvr.
Do you think there could be DMA related problems with
the buffer allocated with drm_gem_get_pages and DMA mapping,
use? So GPU is not able to handle those?
The only source of knowledge at the moment I have is
publicly available pvrsrvkm kernel module. But there are
other unknowns, e.g. user-space libraries, firmware which
are in binary form: thus kernel driver is mostly a bridge
between FW and libs. That being said, do you think I have to get
deeper into GPU use-case or should I switch back to alloc_pages+
remap_pfn_range? ;)
> BR,
> -R
>
>>>
>>> BR,
>>> -R
>> Thank you,
>> Oleksandr
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-03-20 18:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-17 17:39 GEM allocation for para-virtualized DRM driver Oleksandr Andrushchenko
2017-03-18 12:22 ` Rob Clark
2017-03-18 13:25 ` Oleksandr Andrushchenko
2017-03-18 14:06 ` Rob Clark
2017-03-18 14:44 ` Oleksandr Andrushchenko
2017-03-18 14:50 ` Rob Clark
2017-03-18 14:56 ` Oleksandr Andrushchenko
2017-03-20 17:18 ` Oleksandr Andrushchenko
2017-03-20 17:38 ` Rob Clark
2017-03-20 18:01 ` Oleksandr Andrushchenko [this message]
2017-03-20 18:17 ` Rob Clark
2017-03-20 18:25 ` Oleksandr Andrushchenko
2017-03-20 18:52 ` Rob Clark
2017-03-20 19:05 ` Oleksandr Andrushchenko
2017-03-21 15:12 ` Oleksandr Andrushchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=93a21d4e-8fcf-fa84-db68-738fcc294950@gmail.com \
--to=andr2000@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=robdclark@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).