From: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
To: Hyungwon Hwang <human.hwang@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org,
dri-devel@lists.freedesktop.org, emil.l.velikov@gmail.com,
jy0922.shim@samsung.com, gustavo.padovan@collabora.co.uk,
inki.dae@samsung.com
Subject: Re: [PATCH 09/13] exynos/fimg2d: add g2d_move
Date: Tue, 10 Nov 2015 14:24:11 +0100 [thread overview]
Message-ID: <5641EFFB.1020509@math.uni-bielefeld.de> (raw)
In-Reply-To: <20151110132005.73ff2b60@hwh-ubuntu>
Hello Hyungwon,
Hyungwon Hwang wrote:
> Hello Tobias,
>
> On Mon, 09 Nov 2015 10:47:02 +0100
> Tobias Jakobi <tjakobi@math.uni-bielefeld.de> wrote:
>
>> Hello Hyungwon,
>>
>>
>> Hyungwon Hwang wrote:
>>> Hello Tobias,
>>>
>>> I was in vacation last week, so I could run your code today. I found
>>> that what g2d_move() does is actually copying not moving, because
>>> the operation does not clear the previous area.
>> I choose g2d_move() because we also have memcpy() and memmove() in
>> libc. Like in libc 'moving' memory doesn't actually move it, like you
>> would move a real object, since it's undefined what 'empty' memory
>> should be.
>>
>> The same applies here. It's not defined what 'empty' areas of the
>> buffer should be.
>>
>>
>>> Would it be possible to
>>> generalize g2d_copy() works better, so it could works well in case
>>> of the src buffer and dst buffer being same.
>> I think this would break g2d_copy() backward compatibility.
>>
>> I also want the user to explicitly request this. The user should make
>> sure what requirements he has for the buffers in question. Are the
>> buffers disjoint or not?
>>
>>
>>> If it is possible, I think it
>>> would be better way to do that. If it is not, at least chaning the
>>> function name is needed. I tested it on my Odroid U3 board.
>> I don't have a strong opinion on the naming. Any recommendations?
>>
>> I still think the naming is fine though, since it mirrors libc's
>> naming. And the user is supposed to read the documentation anyway.
>
>>
>>
>>
>> With best wishes,
>> Tobias
>
> In that manner following glibc, I agree that the naming is reasonable.
well, that was just my way of thinking. But I guess most people have
experience using the libc, so the naming should look at least 'familiar'.
> I commented like that previously, because at the first time when I run
> the test, I think that the result seems like a bug. The test program
> said that it was a move test, but the operation seemed copying.
Ok, so just that I understand this correctly. Your issue is with the
commit the description of the test or with the commit description of the
patch that introduces g2d_move()?
Because I don't see what you point out in the test commit description:
"
tests/exynos: add test for g2d_move
To check if g2d_move() works properly we create a small checkerboard
pattern in the center of the screen and then shift this pattern
around with g2d_move(). The pattern should be properly preserved
by the operation.
"
I intentionally avoid to write "...move this pattern around...", so
instead I choose "shift".
I'm not a native speaker, so I'm clueless how to formulate this in a
more clear way.
> It
> would be just OK if it is well documented or printed when runs the test
> that the test does not do anything about the previous area
> intentionally.
I could add solid fills of the 'empty' areas after each move()
operation. Would that be more in line what you think the test should do?
With best wishes,
Tobias
>
>
> BRs,
> Hyungwon Hwang
>
next prev parent reply other threads:[~2015-11-10 13:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 15:54 [PATCH 00/13] drm/exynos: async G2D and g2d_move() Tobias Jakobi
2015-09-22 15:54 ` [PATCH 01/13] drm: Implement drmHandleEvent2() Tobias Jakobi
2015-09-22 15:54 ` [PATCH 02/13] exynos: Introduce exynos_handle_event() Tobias Jakobi
2015-09-22 15:54 ` [PATCH 03/13] tests/exynos: add fimg2d performance analysis Tobias Jakobi
2015-10-30 6:51 ` Hyungwon Hwang
2015-10-30 11:17 ` Tobias Jakobi
2015-09-22 15:54 ` [PATCH 04/13] exynos/fimg2d: add g2d_config_event Tobias Jakobi
2015-09-22 15:54 ` [PATCH 05/13] exynos: fimg2d: add g2d_exec2 Tobias Jakobi
2015-09-22 15:54 ` [PATCH 06/13] tests/exynos: add fimg2d event test Tobias Jakobi
2015-10-30 6:50 ` Hyungwon Hwang
2015-10-30 11:16 ` Tobias Jakobi
2015-10-30 11:24 ` Emil Velikov
2015-10-30 11:28 ` Tobias Jakobi
2015-10-30 12:31 ` Emil Velikov
2015-10-30 14:28 ` Tobias Jakobi
2015-10-30 18:49 ` Emil Velikov
2015-11-02 2:10 ` Hyungwon Hwang
2015-09-22 15:54 ` [PATCH 07/13] tests/exynos: use XRGB8888 for framebuffer Tobias Jakobi
2015-10-30 6:41 ` Hyungwon Hwang
2015-10-30 11:17 ` Tobias Jakobi
2015-11-02 2:32 ` Hyungwon Hwang
2015-09-22 15:54 ` [PATCH 08/13] exynos: fimg2d: add g2d_set_direction Tobias Jakobi
2015-10-30 7:14 ` Hyungwon Hwang
2015-10-30 11:17 ` Tobias Jakobi
2015-10-30 17:14 ` Tobias Jakobi
2015-11-02 4:28 ` Hyungwon Hwang
2015-09-22 15:54 ` [PATCH 09/13] exynos/fimg2d: add g2d_move Tobias Jakobi
2015-10-30 7:17 ` Hyungwon Hwang
2015-10-30 11:18 ` Tobias Jakobi
2015-11-09 7:30 ` Hyungwon Hwang
2015-11-09 9:47 ` Tobias Jakobi
2015-11-10 4:20 ` Hyungwon Hwang
2015-11-10 13:24 ` Tobias Jakobi [this message]
2015-11-11 1:55 ` Hyungwon Hwang
2015-09-22 15:54 ` [PATCH 10/13] tests/exynos: add test for g2d_move Tobias Jakobi
2015-11-09 7:36 ` Hyungwon Hwang
2015-11-09 9:47 ` Tobias Jakobi
2015-11-09 11:33 ` Emil Velikov
2015-09-22 15:55 ` [PATCH 11/13] exynos/fimg2d: add exynos_bo_unmap() Tobias Jakobi
2015-09-22 15:55 ` [PATCH 12/13] exynos/fimg2d: add g2d_reset() to public API Tobias Jakobi
2015-09-22 15:55 ` [PATCH 13/13] exynos: bump version number Tobias Jakobi
2015-10-07 18:32 ` [PATCH 00/13] drm/exynos: async G2D and g2d_move() Tobias Jakobi
2015-10-17 22:39 ` Tobias Jakobi
2015-10-28 19:27 ` Tobias Jakobi
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=5641EFFB.1020509@math.uni-bielefeld.de \
--to=tjakobi@math.uni-bielefeld.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=gustavo.padovan@collabora.co.uk \
--cc=human.hwang@samsung.com \
--cc=inki.dae@samsung.com \
--cc=jy0922.shim@samsung.com \
--cc=linux-samsung-soc@vger.kernel.org \
/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