[PATCH] libdrm/exynos: add test application for 2d gpu.
On Mon, Feb 18, 2013 at 7:51 AM, Inki Dae wrote:
> This patch adds library and test application for g2d gpu(fimg2d).
>
> The fimg2d hardware is a 2D graphics accelerator(G2D) that
> supports Bit Block Transfer(BitBLT).
>
> The library includes the following primitive drawing operations:
> .solid fill - This operation fills the given buffer with
> the given color data.
> .copy - This operation copies contents in source buffer to
> destination buffer.
> .copy_with_scale - This operation copies contents in source buffer
> to destination buffer scaling up or down properly.
> .blend - This operation blends contents in source buffer with
> the ones in destination buffer.
>
> And the above operations uses gem handle or user space address
> allocated by malloc() as source or destination buffer.
>
> And the test application includes just simple primitive drawing
> tests with the above library.
> And the guide to test is as the following,
> "#exynos_fimg2d_test -s connector_id at crtc_id:mode"
>
> With this above simple command, four primitive drawing operations
> would be called step by step and also rendered on the output device
> to the given connector and crtc id.
>
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
Fyi, I've pushed this now to libdrm tree
BR,
-R
> ---
> configure.ac |1 +
> exynos/Makefile.am|2 +-
> exynos/exynos_drm.h | 52 +++
> exynos/exynos_fimg2d.c| 630 +
> exynos/fimg2d.h | 325 +
> exynos/fimg2d_reg.h | 114 ++
> tests/Makefile.am |4 +
> tests/exynos/Makefile.am | 19 +
> tests/exynos/exynos_fimg2d_test.c | 695
> +
> 9 files changed, 1841 insertions(+), 1 deletions(-)
> create mode 100644 exynos/exynos_fimg2d.c
> create mode 100644 exynos/fimg2d.h
> create mode 100644 exynos/fimg2d_reg.h
> create mode 100644 tests/exynos/Makefile.am
> create mode 100644 tests/exynos/exynos_fimg2d_test.c
>
> diff --git a/configure.ac b/configure.ac
> index e2e3466..2896f91 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -364,6 +364,7 @@ AC_CONFIG_FILES([
> tests/kmstest/Makefile
> tests/radeon/Makefile
> tests/vbltest/Makefile
> + tests/exynos/Makefile
> include/Makefile
> include/drm/Makefile
> man/Makefile
> diff --git a/exynos/Makefile.am b/exynos/Makefile.am
> index e782d34..539aea0 100644
> --- a/exynos/Makefile.am
> +++ b/exynos/Makefile.am
> @@ -10,7 +10,7 @@ libdrm_exynos_ladir = $(libdir)
> libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
> libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
>
> -libdrm_exynos_la_SOURCES = exynos_drm.c
> +libdrm_exynos_la_SOURCES = exynos_drm.c exynos_fimg2d.c
>
> libdrm_exynoscommonincludedir = ${includedir}/exynos
> libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
> diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
> index aa97b22..c3c6579 100644
> --- a/exynos/exynos_drm.h
> +++ b/exynos/exynos_drm.h
> @@ -123,6 +123,46 @@ enum e_drm_exynos_gem_mem_type {
> EXYNOS_BO_WC
> };
>
> +struct drm_exynos_g2d_get_ver {
> + __u32 major;
> + __u32 minor;
> +};
> +
> +struct drm_exynos_g2d_cmd {
> + __u32 offset;
> + __u32 data;
> +};
> +
> +enum drm_exynos_g2d_buf_type {
> + G2D_BUF_USERPTR = 1 << 31,
> +};
> +
> +enum drm_exynos_g2d_event_type {
> + G2D_EVENT_NOT,
> + G2D_EVENT_NONSTOP,
> + G2D_EVENT_STOP, /* not yet */
> +};
> +
> +struct drm_exynos_g2d_userptr {
> + unsigned long userptr;
> + unsigned long size;
> +};
> +
> +struct drm_exynos_g2d_set_cmdlist {
> + __u64 cmd;
> + __u64 cmd_buf;
> + __u32 cmd_nr;
> + __u32 cmd_buf_nr;
> +
> + /* for g2d event */
> + __u64 event_type;
> + __u64 user_data;
> +};
> +
> +struct drm_exynos_g2d_exec {
> + __u64 async;
> +};
> +
> #define DRM_EXYNOS_GEM_CREATE 0x00
> #define DRM_EXYNOS_GEM_MAP_OFFSET 0x01
> #define DRM_EXYNOS_GEM_MMAP0x02
> @@ -130,6 +170,11 @@ enum e_drm_exynos_gem_mem_type {
> #define DRM_EXYNOS_GEM_GET 0x04
> #define DRM_EXYNOS_VIDI_CONNECTION 0x07
>
> +/* G2D */
> +#define DRM_EXYNOS_G2D_GET_VER 0x20
> +#define DRM_EXYNOS_G2D_SET_CMDLIST 0x21
> +#define DRM_EXYNOS_G2D_EXEC0x22
> +
> #define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
> DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
>
> @@ -145,4 +190,11 @@ enum e_drm_
[PATCH] libdrm/exynos: add test application for 2d gpu.
2013/3/3 Rob Clark : > On Sat, Mar 2, 2013 at 2:28 AM, Inki Dae wrote: >> Actually, we have already implemented the EXA part of X server and >> that has being used on our linux platform. But I think we could more >> improvement this. So are you writting user side g2d drivers for Chrome >> book(based on Exynos5250 SoC)? And do you want to improment this? > > Oh, ok.. I was under the impression that this did not exist. > > Well, when I receive my chromebook, I'll take a look, and see what > else is needed for a more traditional x11 desktop. Where is the git > tree? > Sorry for late answer. Unfurtunately, the EXA module isn't published yet so I'm checking if that module could be published now. so much complicated. :( As soon as checked, I'll let you know. Thanks, Inki Dae > BR, > -R > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] libdrm/exynos: add test application for 2d gpu.
2013/3/3 Rob Clark : > On Sat, Mar 2, 2013 at 2:28 AM, Inki Dae wrote: >> Actually, we have already implemented the EXA part of X server and >> that has being used on our linux platform. But I think we could more >> improvement this. So are you writting user side g2d drivers for Chrome >> book(based on Exynos5250 SoC)? And do you want to improment this? > > Oh, ok.. I was under the impression that this did not exist. > > Well, when I receive my chromebook, I'll take a look, and see what > else is needed for a more traditional x11 desktop. Where is the git > tree? > Sorry for late answer. Unfurtunately, the EXA module isn't published yet so I'm checking if that module could be published now. so much complicated. :( As soon as checked, I'll let you know. Thanks, Inki Dae > BR, > -R > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] libdrm/exynos: add test application for 2d gpu.
2013/3/1 Rob Clark : > On Fri, Mar 1, 2013 at 1:52 AM, Inki Dae wrote: >> 2013/3/1 Rob Clark : >>> Just curious, but the 2d blitter have it's own sort of >>> command-processor, ie. can you feed it a list of different blits in >>> one batch and then it will process them one after another? >>> >> >> Right, the command lists are processed by the dma. One command list >> links up with another one so the dma can process these command lists >> in sequence. > > hmm, does this mean cmd-list entries have paddr to next cmdlist entry? > Right, that could be physical address or device address(with iommu). User space could set only user space address or gem handle and then they are changed to physicall adress or device address in kernel space because of security issue. This way would have some overhead definitely(for this, Tegra guy had also posted) but there is no any better way yet :( > for EXA you could end up with everything from very small blits to > large ones.. ideally you want to minimize the overhead for blit n+1 > which is why I'm not hugely fond of the one ioctl per blit. > Actually, user side could assamble small pipe line commands into one blit command set we want. Ideally, such stubs of user side should be provided. This patch is just a sample application for testing the drm based g2d driver. >>> If so, that would make the separate ioctls for SET_CMDLIST on each >>> blit operation, and then EXEC a bit awkward, and give you a huge # of >>> ioctls for something like EXA/x11 trying to use the blitter. >>> >> >> Yes, it's possible scenario. But the g2d driver can have maximum 64 >> command list nodes which are processed by the dma directly so if >> exceeded then it returns some error. > > well, the 64 limit can be handled, I suspect, on the kernel side. > Maybe the limitation is different on some future different version of > the blitter, etc. > This is not hardware limitation so could be extended to huge size as much as we want. >> For detail, one command list from user(through SET_CMDLIST ioctl) is >> copied to a free command list node got from a free list that has >> maximum 64 command list nodes. And then the command list is placed in >> inuse_cmdlist and then if EXEC ioctl is called by user, all nodes of >> the inuse_cmdlist are moved to run_cmdlist and then the nodes of the >> run_cmdlist are processed by the dma in sequence. >> >>> Is there some documentation about G2D somewhere that I could read? >> >> Do you need some documents about G2D hardware? If so, I'm afriad that >> I couldn't give you the document because I have no any public version >> document about it. Sorry for this. > > hmm, it certainly would be easier to write the EXA/userspace parts, > and maybe even make some improvements on the kernel side if needed, > with a bit of documentation about what the blitter can do and how to > program it.. granted I've written drivers with less information, but > it is a more time consuming process (and at least in that case I had a > userspace blob that I could observe via LD_PRELOAD shim).. > Actually, we have already implemented the EXA part of X server and that has being used on our linux platform. But I think we could more improvement this. So are you writting user side g2d drivers for Chrome book(based on Exynos5250 SoC)? And do you want to improment this? Thanks, Inki Dae > BR, > -R > >> Thanks, >> Inki Dae >> >>> Just curious, because I have a chromebook on the way and was wondering >>> about trying to give x11 a bit help by means of G2D.. >>> >>> BR, >>> -R >>> >>> >>> On Mon, Feb 18, 2013 at 7:51 AM, Inki Dae wrote: This patch adds library and test application for g2d gpu(fimg2d). The fimg2d hardware is a 2D graphics accelerator(G2D) that supports Bit Block Transfer(BitBLT). The library includes the following primitive drawing operations: .solid fill - This operation fills the given buffer with the given color data. .copy - This operation copies contents in source buffer to destination buffer. .copy_with_scale - This operation copies contents in source buffer to destination buffer scaling up or down properly. .blend - This operation blends contents in source buffer with the ones in destination buffer. And the above operations uses gem handle or user space address allocated by malloc() as source or destination buffer. And the test application includes just simple primitive drawing tests with the above library. And the guide to test is as the following, "#exynos_fimg2d_test -s connector_id at crtc_id:mode" With this above simple command, four primitive drawing operations would be called step by step and also rendered on the output device to the given connector and crtc id. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- configure.ac |1 + exynos/Make
[PATCH] libdrm/exynos: add test application for 2d gpu.
On Sat, Mar 2, 2013 at 2:28 AM, Inki Dae wrote: > Actually, we have already implemented the EXA part of X server and > that has being used on our linux platform. But I think we could more > improvement this. So are you writting user side g2d drivers for Chrome > book(based on Exynos5250 SoC)? And do you want to improment this? Oh, ok.. I was under the impression that this did not exist. Well, when I receive my chromebook, I'll take a look, and see what else is needed for a more traditional x11 desktop. Where is the git tree? BR, -R
Re: [PATCH] libdrm/exynos: add test application for 2d gpu.
On Sat, Mar 2, 2013 at 2:28 AM, Inki Dae wrote: > Actually, we have already implemented the EXA part of X server and > that has being used on our linux platform. But I think we could more > improvement this. So are you writting user side g2d drivers for Chrome > book(based on Exynos5250 SoC)? And do you want to improment this? Oh, ok.. I was under the impression that this did not exist. Well, when I receive my chromebook, I'll take a look, and see what else is needed for a more traditional x11 desktop. Where is the git tree? BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] libdrm/exynos: add test application for 2d gpu.
2013/3/1 Rob Clark :
> Just curious, but the 2d blitter have it's own sort of
> command-processor, ie. can you feed it a list of different blits in
> one batch and then it will process them one after another?
>
Right, the command lists are processed by the dma. One command list
links up with another one so the dma can process these command lists
in sequence.
> If so, that would make the separate ioctls for SET_CMDLIST on each
> blit operation, and then EXEC a bit awkward, and give you a huge # of
> ioctls for something like EXA/x11 trying to use the blitter.
>
Yes, it's possible scenario. But the g2d driver can have maximum 64
command list nodes which are processed by the dma directly so if
exceeded then it returns some error.
For detail, one command list from user(through SET_CMDLIST ioctl) is
copied to a free command list node got from a free list that has
maximum 64 command list nodes. And then the command list is placed in
inuse_cmdlist and then if EXEC ioctl is called by user, all nodes of
the inuse_cmdlist are moved to run_cmdlist and then the nodes of the
run_cmdlist are processed by the dma in sequence.
> Is there some documentation about G2D somewhere that I could read?
Do you need some documents about G2D hardware? If so, I'm afriad that
I couldn't give you the document because I have no any public version
document about it. Sorry for this.
Thanks,
Inki Dae
> Just curious, because I have a chromebook on the way and was wondering
> about trying to give x11 a bit help by means of G2D..
>
> BR,
> -R
>
>
> On Mon, Feb 18, 2013 at 7:51 AM, Inki Dae wrote:
>> This patch adds library and test application for g2d gpu(fimg2d).
>>
>> The fimg2d hardware is a 2D graphics accelerator(G2D) that
>> supports Bit Block Transfer(BitBLT).
>>
>> The library includes the following primitive drawing operations:
>> .solid fill - This operation fills the given buffer with
>> the given color data.
>> .copy - This operation copies contents in source buffer to
>> destination buffer.
>> .copy_with_scale - This operation copies contents in source buffer
>> to destination buffer scaling up or down properly.
>> .blend - This operation blends contents in source buffer with
>> the ones in destination buffer.
>>
>> And the above operations uses gem handle or user space address
>> allocated by malloc() as source or destination buffer.
>>
>> And the test application includes just simple primitive drawing
>> tests with the above library.
>> And the guide to test is as the following,
>> "#exynos_fimg2d_test -s connector_id at crtc_id:mode"
>>
>> With this above simple command, four primitive drawing operations
>> would be called step by step and also rendered on the output device
>> to the given connector and crtc id.
>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> configure.ac |1 +
>> exynos/Makefile.am|2 +-
>> exynos/exynos_drm.h | 52 +++
>> exynos/exynos_fimg2d.c| 630 +
>> exynos/fimg2d.h | 325 +
>> exynos/fimg2d_reg.h | 114 ++
>> tests/Makefile.am |4 +
>> tests/exynos/Makefile.am | 19 +
>> tests/exynos/exynos_fimg2d_test.c | 695
>> +
>> 9 files changed, 1841 insertions(+), 1 deletions(-)
>> create mode 100644 exynos/exynos_fimg2d.c
>> create mode 100644 exynos/fimg2d.h
>> create mode 100644 exynos/fimg2d_reg.h
>> create mode 100644 tests/exynos/Makefile.am
>> create mode 100644 tests/exynos/exynos_fimg2d_test.c
>>
>> diff --git a/configure.ac b/configure.ac
>> index e2e3466..2896f91 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -364,6 +364,7 @@ AC_CONFIG_FILES([
>> tests/kmstest/Makefile
>> tests/radeon/Makefile
>> tests/vbltest/Makefile
>> + tests/exynos/Makefile
>> include/Makefile
>> include/drm/Makefile
>> man/Makefile
>> diff --git a/exynos/Makefile.am b/exynos/Makefile.am
>> index e782d34..539aea0 100644
>> --- a/exynos/Makefile.am
>> +++ b/exynos/Makefile.am
>> @@ -10,7 +10,7 @@ libdrm_exynos_ladir = $(libdir)
>> libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
>> libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
>>
>> -libdrm_exynos_la_SOURCES = exynos_drm.c
>> +libdrm_exynos_la_SOURCES = exynos_drm.c exynos_fimg2d.c
>>
>> libdrm_exynoscommonincludedir = ${includedir}/exynos
>> libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
>> diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
>> index aa97b22..c3c6579 100644
>> --- a/exynos/exynos_drm.h
>> +++ b/exynos/exynos_drm.h
>> @@ -123,6 +123,46 @@ enum e_drm_exynos_gem_mem_type {
>> EXYNOS_BO_WC
>> };
>>
>> +struct drm_exynos_g2d_get_ver {
>> + __u32 major;
>> + __u32 minor;
>> +};
>> +
>> +struct drm_exynos_g2d_
[PATCH] libdrm/exynos: add test application for 2d gpu.
On Fri, Mar 1, 2013 at 1:52 AM, Inki Dae wrote: > 2013/3/1 Rob Clark : >> Just curious, but the 2d blitter have it's own sort of >> command-processor, ie. can you feed it a list of different blits in >> one batch and then it will process them one after another? >> > > Right, the command lists are processed by the dma. One command list > links up with another one so the dma can process these command lists > in sequence. hmm, does this mean cmd-list entries have paddr to next cmdlist entry? for EXA you could end up with everything from very small blits to large ones.. ideally you want to minimize the overhead for blit n+1 which is why I'm not hugely fond of the one ioctl per blit. >> If so, that would make the separate ioctls for SET_CMDLIST on each >> blit operation, and then EXEC a bit awkward, and give you a huge # of >> ioctls for something like EXA/x11 trying to use the blitter. >> > > Yes, it's possible scenario. But the g2d driver can have maximum 64 > command list nodes which are processed by the dma directly so if > exceeded then it returns some error. well, the 64 limit can be handled, I suspect, on the kernel side. Maybe the limitation is different on some future different version of the blitter, etc. > For detail, one command list from user(through SET_CMDLIST ioctl) is > copied to a free command list node got from a free list that has > maximum 64 command list nodes. And then the command list is placed in > inuse_cmdlist and then if EXEC ioctl is called by user, all nodes of > the inuse_cmdlist are moved to run_cmdlist and then the nodes of the > run_cmdlist are processed by the dma in sequence. > >> Is there some documentation about G2D somewhere that I could read? > > Do you need some documents about G2D hardware? If so, I'm afriad that > I couldn't give you the document because I have no any public version > document about it. Sorry for this. hmm, it certainly would be easier to write the EXA/userspace parts, and maybe even make some improvements on the kernel side if needed, with a bit of documentation about what the blitter can do and how to program it.. granted I've written drivers with less information, but it is a more time consuming process (and at least in that case I had a userspace blob that I could observe via LD_PRELOAD shim).. BR, -R > Thanks, > Inki Dae > >> Just curious, because I have a chromebook on the way and was wondering >> about trying to give x11 a bit help by means of G2D.. >> >> BR, >> -R >> >> >> On Mon, Feb 18, 2013 at 7:51 AM, Inki Dae wrote: >>> This patch adds library and test application for g2d gpu(fimg2d). >>> >>> The fimg2d hardware is a 2D graphics accelerator(G2D) that >>> supports Bit Block Transfer(BitBLT). >>> >>> The library includes the following primitive drawing operations: >>> .solid fill - This operation fills the given buffer with >>> the given color data. >>> .copy - This operation copies contents in source buffer to >>> destination buffer. >>> .copy_with_scale - This operation copies contents in source buffer >>> to destination buffer scaling up or down properly. >>> .blend - This operation blends contents in source buffer with >>> the ones in destination buffer. >>> >>> And the above operations uses gem handle or user space address >>> allocated by malloc() as source or destination buffer. >>> >>> And the test application includes just simple primitive drawing >>> tests with the above library. >>> And the guide to test is as the following, >>> "#exynos_fimg2d_test -s connector_id at crtc_id:mode" >>> >>> With this above simple command, four primitive drawing operations >>> would be called step by step and also rendered on the output device >>> to the given connector and crtc id. >>> >>> Signed-off-by: Inki Dae >>> Signed-off-by: Kyungmin Park >>> --- >>> configure.ac |1 + >>> exynos/Makefile.am|2 +- >>> exynos/exynos_drm.h | 52 +++ >>> exynos/exynos_fimg2d.c| 630 + >>> exynos/fimg2d.h | 325 + >>> exynos/fimg2d_reg.h | 114 ++ >>> tests/Makefile.am |4 + >>> tests/exynos/Makefile.am | 19 + >>> tests/exynos/exynos_fimg2d_test.c | 695 >>> + >>> 9 files changed, 1841 insertions(+), 1 deletions(-) >>> create mode 100644 exynos/exynos_fimg2d.c >>> create mode 100644 exynos/fimg2d.h >>> create mode 100644 exynos/fimg2d_reg.h >>> create mode 100644 tests/exynos/Makefile.am >>> create mode 100644 tests/exynos/exynos_fimg2d_test.c >>> >>> diff --git a/configure.ac b/configure.ac >>> index e2e3466..2896f91 100644 >>> --- a/configure.ac >>> +++ b/configure.ac >>> @@ -364,6 +364,7 @@ AC_CONFIG_FILES([ >>> tests/kmstest/Makefile >>> tests/radeon/Makefile >>> tests/vbltest/Makefile >>> + tests/exynos/Makefile >>> include/Makefile >>
[PATCH] libdrm/exynos: add test application for 2d gpu.
Just curious, but the 2d blitter have it's own sort of
command-processor, ie. can you feed it a list of different blits in
one batch and then it will process them one after another?
If so, that would make the separate ioctls for SET_CMDLIST on each
blit operation, and then EXEC a bit awkward, and give you a huge # of
ioctls for something like EXA/x11 trying to use the blitter.
Is there some documentation about G2D somewhere that I could read?
Just curious, because I have a chromebook on the way and was wondering
about trying to give x11 a bit help by means of G2D..
BR,
-R
On Mon, Feb 18, 2013 at 7:51 AM, Inki Dae wrote:
> This patch adds library and test application for g2d gpu(fimg2d).
>
> The fimg2d hardware is a 2D graphics accelerator(G2D) that
> supports Bit Block Transfer(BitBLT).
>
> The library includes the following primitive drawing operations:
> .solid fill - This operation fills the given buffer with
> the given color data.
> .copy - This operation copies contents in source buffer to
> destination buffer.
> .copy_with_scale - This operation copies contents in source buffer
> to destination buffer scaling up or down properly.
> .blend - This operation blends contents in source buffer with
> the ones in destination buffer.
>
> And the above operations uses gem handle or user space address
> allocated by malloc() as source or destination buffer.
>
> And the test application includes just simple primitive drawing
> tests with the above library.
> And the guide to test is as the following,
> "#exynos_fimg2d_test -s connector_id at crtc_id:mode"
>
> With this above simple command, four primitive drawing operations
> would be called step by step and also rendered on the output device
> to the given connector and crtc id.
>
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
> configure.ac |1 +
> exynos/Makefile.am|2 +-
> exynos/exynos_drm.h | 52 +++
> exynos/exynos_fimg2d.c| 630 +
> exynos/fimg2d.h | 325 +
> exynos/fimg2d_reg.h | 114 ++
> tests/Makefile.am |4 +
> tests/exynos/Makefile.am | 19 +
> tests/exynos/exynos_fimg2d_test.c | 695
> +
> 9 files changed, 1841 insertions(+), 1 deletions(-)
> create mode 100644 exynos/exynos_fimg2d.c
> create mode 100644 exynos/fimg2d.h
> create mode 100644 exynos/fimg2d_reg.h
> create mode 100644 tests/exynos/Makefile.am
> create mode 100644 tests/exynos/exynos_fimg2d_test.c
>
> diff --git a/configure.ac b/configure.ac
> index e2e3466..2896f91 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -364,6 +364,7 @@ AC_CONFIG_FILES([
> tests/kmstest/Makefile
> tests/radeon/Makefile
> tests/vbltest/Makefile
> + tests/exynos/Makefile
> include/Makefile
> include/drm/Makefile
> man/Makefile
> diff --git a/exynos/Makefile.am b/exynos/Makefile.am
> index e782d34..539aea0 100644
> --- a/exynos/Makefile.am
> +++ b/exynos/Makefile.am
> @@ -10,7 +10,7 @@ libdrm_exynos_ladir = $(libdir)
> libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
> libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
>
> -libdrm_exynos_la_SOURCES = exynos_drm.c
> +libdrm_exynos_la_SOURCES = exynos_drm.c exynos_fimg2d.c
>
> libdrm_exynoscommonincludedir = ${includedir}/exynos
> libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
> diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
> index aa97b22..c3c6579 100644
> --- a/exynos/exynos_drm.h
> +++ b/exynos/exynos_drm.h
> @@ -123,6 +123,46 @@ enum e_drm_exynos_gem_mem_type {
> EXYNOS_BO_WC
> };
>
> +struct drm_exynos_g2d_get_ver {
> + __u32 major;
> + __u32 minor;
> +};
> +
> +struct drm_exynos_g2d_cmd {
> + __u32 offset;
> + __u32 data;
> +};
> +
> +enum drm_exynos_g2d_buf_type {
> + G2D_BUF_USERPTR = 1 << 31,
> +};
> +
> +enum drm_exynos_g2d_event_type {
> + G2D_EVENT_NOT,
> + G2D_EVENT_NONSTOP,
> + G2D_EVENT_STOP, /* not yet */
> +};
> +
> +struct drm_exynos_g2d_userptr {
> + unsigned long userptr;
> + unsigned long size;
> +};
> +
> +struct drm_exynos_g2d_set_cmdlist {
> + __u64 cmd;
> + __u64 cmd_buf;
> + __u32 cmd_nr;
> + __u32 cmd_buf_nr;
> +
> + /* for g2d event */
> + __u64 event_type;
> + __u64 user_data;
> +};
> +
> +struct drm_exynos_g2d_exec {
> + __u64 async;
> +};
> +
> #define DRM_EXYNOS_GEM_CREATE 0x00
> #define DRM_EXYNOS_GEM_MAP_OFFSET 0x01
> #define D
[PATCH] libdrm/exynos: add test application for 2d gpu.
This patch adds library and test application for g2d gpu(fimg2d).
The fimg2d hardware is a 2D graphics accelerator(G2D) that
supports Bit Block Transfer(BitBLT).
The library includes the following primitive drawing operations:
.solid fill - This operation fills the given buffer with
the given color data.
.copy - This operation copies contents in source buffer to
destination buffer.
.copy_with_scale - This operation copies contents in source buffer
to destination buffer scaling up or down properly.
.blend - This operation blends contents in source buffer with
the ones in destination buffer.
And the above operations uses gem handle or user space address
allocated by malloc() as source or destination buffer.
And the test application includes just simple primitive drawing
tests with the above library.
And the guide to test is as the following,
"#exynos_fimg2d_test -s connector_id at crtc_id:mode"
With this above simple command, four primitive drawing operations
would be called step by step and also rendered on the output device
to the given connector and crtc id.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
configure.ac |1 +
exynos/Makefile.am|2 +-
exynos/exynos_drm.h | 52 +++
exynos/exynos_fimg2d.c| 630 +
exynos/fimg2d.h | 325 +
exynos/fimg2d_reg.h | 114 ++
tests/Makefile.am |4 +
tests/exynos/Makefile.am | 19 +
tests/exynos/exynos_fimg2d_test.c | 695 +
9 files changed, 1841 insertions(+), 1 deletions(-)
create mode 100644 exynos/exynos_fimg2d.c
create mode 100644 exynos/fimg2d.h
create mode 100644 exynos/fimg2d_reg.h
create mode 100644 tests/exynos/Makefile.am
create mode 100644 tests/exynos/exynos_fimg2d_test.c
diff --git a/configure.ac b/configure.ac
index e2e3466..2896f91 100644
--- a/configure.ac
+++ b/configure.ac
@@ -364,6 +364,7 @@ AC_CONFIG_FILES([
tests/kmstest/Makefile
tests/radeon/Makefile
tests/vbltest/Makefile
+ tests/exynos/Makefile
include/Makefile
include/drm/Makefile
man/Makefile
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
index e782d34..539aea0 100644
--- a/exynos/Makefile.am
+++ b/exynos/Makefile.am
@@ -10,7 +10,7 @@ libdrm_exynos_ladir = $(libdir)
libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-libdrm_exynos_la_SOURCES = exynos_drm.c
+libdrm_exynos_la_SOURCES = exynos_drm.c exynos_fimg2d.c
libdrm_exynoscommonincludedir = ${includedir}/exynos
libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
index aa97b22..c3c6579 100644
--- a/exynos/exynos_drm.h
+++ b/exynos/exynos_drm.h
@@ -123,6 +123,46 @@ enum e_drm_exynos_gem_mem_type {
EXYNOS_BO_WC
};
+struct drm_exynos_g2d_get_ver {
+ __u32 major;
+ __u32 minor;
+};
+
+struct drm_exynos_g2d_cmd {
+ __u32 offset;
+ __u32 data;
+};
+
+enum drm_exynos_g2d_buf_type {
+ G2D_BUF_USERPTR = 1 << 31,
+};
+
+enum drm_exynos_g2d_event_type {
+ G2D_EVENT_NOT,
+ G2D_EVENT_NONSTOP,
+ G2D_EVENT_STOP, /* not yet */
+};
+
+struct drm_exynos_g2d_userptr {
+ unsigned long userptr;
+ unsigned long size;
+};
+
+struct drm_exynos_g2d_set_cmdlist {
+ __u64 cmd;
+ __u64 cmd_buf;
+ __u32 cmd_nr;
+ __u32 cmd_buf_nr;
+
+ /* for g2d event */
+ __u64 event_type;
+ __u64 user_data;
+};
+
+struct drm_exynos_g2d_exec {
+ __u64 async;
+};
+
#define DRM_EXYNOS_GEM_CREATE 0x00
#define DRM_EXYNOS_GEM_MAP_OFFSET 0x01
#define DRM_EXYNOS_GEM_MMAP0x02
@@ -130,6 +170,11 @@ enum e_drm_exynos_gem_mem_type {
#define DRM_EXYNOS_GEM_GET 0x04
#define DRM_EXYNOS_VIDI_CONNECTION 0x07
+/* G2D */
+#define DRM_EXYNOS_G2D_GET_VER 0x20
+#define DRM_EXYNOS_G2D_SET_CMDLIST 0x21
+#define DRM_EXYNOS_G2D_EXEC0x22
+
#define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
@@ -145,4 +190,11 @@ enum e_drm_exynos_gem_mem_type {
#define DRM_IOCTL_EXYNOS_VIDI_CONNECTION DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_VIDI_CONNECTION, struct drm_exynos_vidi_connection)
+#define DRM_IOCTL_EXYNOS_G2D_GET_VER DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_EXYNOS_G2D_GET_VER, struct drm_exynos_g2d_get_ver)
+#define DRM_IOCTL_EXYNOS_G2D_SET_
[PATCH] libdrm/exynos: add test application for 2d gpu.
This patch adds library and test application for g2d gpu(fimg2d).
The fimg2d hardware is a 2D graphics accelerator(G2D) that
supports Bit Block Transfer(BitBLT).
The library includes the following primitive drawing operations:
.solid fill - This operation fills the given buffer with
the given color data.
.copy - This operation copies contents in source buffer to
destination buffer.
.copy_with_scale - This operation copies contents in source buffer
to destination buffer scaling up or down properly.
.blend - This operation blends contents in source buffer with
the ones in destination buffer.
And the above operations uses gem handle or user space address
allocated by malloc() as source or destination buffer.
And the test application includes just simple primitive drawing
tests with the above library.
And the guide to test is as the following,
"#exynos_fimg2d_test -s connector_id@crtc_id:mode"
With this above simple command, four primitive drawing operations
would be called step by step and also rendered on the output device
to the given connector and crtc id.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
configure.ac |1 +
exynos/Makefile.am|2 +-
exynos/exynos_drm.h | 52 +++
exynos/exynos_fimg2d.c| 630 +
exynos/fimg2d.h | 325 +
exynos/fimg2d_reg.h | 114 ++
tests/Makefile.am |4 +
tests/exynos/Makefile.am | 19 +
tests/exynos/exynos_fimg2d_test.c | 695 +
9 files changed, 1841 insertions(+), 1 deletions(-)
create mode 100644 exynos/exynos_fimg2d.c
create mode 100644 exynos/fimg2d.h
create mode 100644 exynos/fimg2d_reg.h
create mode 100644 tests/exynos/Makefile.am
create mode 100644 tests/exynos/exynos_fimg2d_test.c
diff --git a/configure.ac b/configure.ac
index e2e3466..2896f91 100644
--- a/configure.ac
+++ b/configure.ac
@@ -364,6 +364,7 @@ AC_CONFIG_FILES([
tests/kmstest/Makefile
tests/radeon/Makefile
tests/vbltest/Makefile
+ tests/exynos/Makefile
include/Makefile
include/drm/Makefile
man/Makefile
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
index e782d34..539aea0 100644
--- a/exynos/Makefile.am
+++ b/exynos/Makefile.am
@@ -10,7 +10,7 @@ libdrm_exynos_ladir = $(libdir)
libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-libdrm_exynos_la_SOURCES = exynos_drm.c
+libdrm_exynos_la_SOURCES = exynos_drm.c exynos_fimg2d.c
libdrm_exynoscommonincludedir = ${includedir}/exynos
libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
index aa97b22..c3c6579 100644
--- a/exynos/exynos_drm.h
+++ b/exynos/exynos_drm.h
@@ -123,6 +123,46 @@ enum e_drm_exynos_gem_mem_type {
EXYNOS_BO_WC
};
+struct drm_exynos_g2d_get_ver {
+ __u32 major;
+ __u32 minor;
+};
+
+struct drm_exynos_g2d_cmd {
+ __u32 offset;
+ __u32 data;
+};
+
+enum drm_exynos_g2d_buf_type {
+ G2D_BUF_USERPTR = 1 << 31,
+};
+
+enum drm_exynos_g2d_event_type {
+ G2D_EVENT_NOT,
+ G2D_EVENT_NONSTOP,
+ G2D_EVENT_STOP, /* not yet */
+};
+
+struct drm_exynos_g2d_userptr {
+ unsigned long userptr;
+ unsigned long size;
+};
+
+struct drm_exynos_g2d_set_cmdlist {
+ __u64 cmd;
+ __u64 cmd_buf;
+ __u32 cmd_nr;
+ __u32 cmd_buf_nr;
+
+ /* for g2d event */
+ __u64 event_type;
+ __u64 user_data;
+};
+
+struct drm_exynos_g2d_exec {
+ __u64 async;
+};
+
#define DRM_EXYNOS_GEM_CREATE 0x00
#define DRM_EXYNOS_GEM_MAP_OFFSET 0x01
#define DRM_EXYNOS_GEM_MMAP0x02
@@ -130,6 +170,11 @@ enum e_drm_exynos_gem_mem_type {
#define DRM_EXYNOS_GEM_GET 0x04
#define DRM_EXYNOS_VIDI_CONNECTION 0x07
+/* G2D */
+#define DRM_EXYNOS_G2D_GET_VER 0x20
+#define DRM_EXYNOS_G2D_SET_CMDLIST 0x21
+#define DRM_EXYNOS_G2D_EXEC0x22
+
#define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
@@ -145,4 +190,11 @@ enum e_drm_exynos_gem_mem_type {
#define DRM_IOCTL_EXYNOS_VIDI_CONNECTION DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_VIDI_CONNECTION, struct drm_exynos_vidi_connection)
+#define DRM_IOCTL_EXYNOS_G2D_GET_VER DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_EXYNOS_G2D_GET_VER, struct drm_exynos_g2d_get_ver)
+#define DRM_IOCTL_EXYNOS_G2D_S
