dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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

  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).