Direct Rendering Manager sed by 3.8 Kernel to command GPU in Beaglebone Black

[CoolPerson:-)]

I understand the DRM provides a method for the user space to control GPU in the BBB via API.  Although this may not have been possible with previous versions of the kernels, GPU I guess must have been controlled somehow by other kernels.

I wish to know before the new Kernel, how was the GPU controlled by the kernel without the help of the DRM? We still had HDMI output from the beaglebone and I hope we used the GPU in it even during the previous Kernel versions. 

I am a beginner to the Beaglebone and I hope detailed answer so that I could dig deep into other ends. 

Thank you very much. 

[Robert Nelson]

Technically, we still don't use the "GPU"...

Please read this first:

https://en.wikipedia.org/wiki/Direct_Rendering_Manager

The old "fbdev" driver we used before the current 'drm' driver was:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/da8xx-fb.c

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Uvindu Silva]

Please do not misunderstand my intention to understand this bit of detail as an effort to put a certain part of the development down. 

I suppose we have a , SGX530 3D Graphics Engine , a GPU capable of doing some GPU processing. So it is okay to assume that we are using the processor to do this processing of graphic elements that otherwise is possible to process with a GPU? 

My second very important question is, Why are we not using the GPU at the moment? 

Thank you very much for all your replies. 

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/NhiiScKy7eU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Thu, Apr 9, 2015 at 11:42 AM, Uvindu Silva <IT120...@my.sliit.lk> wrote:
> Please do not misunderstand my intention to understand this bit of detail as
> an effort to put a certain part of the development down.
>
> I suppose we have a , SGX530 3D Graphics Engine , a GPU capable of doing
> some GPU processing. So it is okay to assume that we are using the processor
> to do this processing of graphic elements that otherwise is possible to
> process with a GPU?
>
> My second very important question is, Why are we not using the GPU at the
> moment?

Feel free to contact TI directly on that issue.

[Uvindu Silva]

Dear Robert,

Thank you for your reply. 

Could you please clarify if my idea about this problem is correct?  Are we processing video using the typical 32 bit processor? 

I understood the wiki page about DRM. The only problem I have is why are we not using it when its sounds good to use it? what is the disadvantage?

[Robert Nelson]

On Thu, Apr 9, 2015 at 11:49 AM, Uvindu Silva <IT120...@my.sliit.lk> wrote:
> Dear Robert,
>
> Thank you for your reply.
>
> Could you please clarify if my idea about this problem is correct? Are we
> processing video using the typical 32 bit processor?
>
> I understood the wiki page about DRM. The only problem I have is why are we
> not using it when its sounds good to use it? what is the disadvantage?

Currently, for all the beagleboard.org images we are using "drm" with
all rendering calculations done on the Cortex-A8 core. The GPU is
currently sitting unused.

[Uvindu Silva]

Thanks Robert for your understanding.

I am truly sad the GPU is just sitting there unused. I do not understand what is stopping us from using a piece of silicon that is begging to be used for its consummate talent; graphics processing. I sincerely wish you could tell me why we haven't used it. My instincts tell me that if you do so, it might piss some people off. Probably TI. But I am definitely taking this to their forum.  

I believe the BBB can get much much faster if we could use the GPU. I am a beginer but I guess that is a logical statement as unnecessary CPU load is reduced.

I do not know if Raspberry PI is not using its GPU too. Are all small sized boards not using the GPU inside them?

 

[Robert Nelson]

On Thu, Apr 9, 2015 at 12:10 PM, Uvindu Silva <IT120...@my.sliit.lk> wrote:
> Thanks Robert for your understanding.
>
> I am truly sad the GPU is just sitting there unused. I do not understand
> what is stopping us from using a piece of silicon that is begging to be used
> for its consummate talent; graphics processing. I sincerely wish you could
> tell me why we haven't used it. My instincts tell me that if you do so, it
> might piss some people off. Probably TI. But I am definitely taking this to
> their forum.
>
> I believe the BBB can get much much faster if we could use the GPU. I am a
> beginer but I guess that is a logical statement as unnecessary CPU load is
> reduced.

Feel free to contact TI directly on this issue. Talking about it here
does nothing.

> I do not know if Raspberry PI is not using its GPU too. Are all small sized
> boards not using the GPU inside them?

The PI has an open source mesa driver in development: "vc4"

http://cgit.freedesktop.org/mesa/mesa/log/?qt=grep&q=vc4

Sorry, we have "nothing" that can compete with that in
ImgTec/PowerVR/SGX land, as ImgTec/PowerVR/SGX just doesn't care.

[Uvindu Silva]

Thank you Robert for your time. 

[William Hermans]

Just as a side note. We do have one advantage over the rPI where *the* GPU is concerned. Currently, the rPI *has* to have the GPU enabled, which in turn uses valuable system( shared ) memory. The last I read, on the rPI this can not be disabled. So technically the rPI can not be a true headless system.

Where as with the beaglebone black, we do not have to use the GPU, or give up memory to the GPU. If we do not need / want to.

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Przemek Klosowski]

On Thu, Apr 9, 2015 at 12:10 PM, Uvindu Silva <IT120...@my.sliit.lk> wrote:

> I believe the BBB can get much much faster if we could use the GPU. I am a
> beginer but I guess that is a logical statement as unnecessary CPU load is
> reduced.

Just so that we are all on the same page, it would be neat if we could offload graphics processing (and maybe other types of processing) to the GPU. This is actually a trend now in x86 world, with both AMD, Nvidia and Intel making multiple cores available for graphics and general processing, Larabee style.

Unfortunately, in the ARM world the GPUs tend to be more proprietary. On BBB, the PowerVR SGX530 GPU was licensed by TI from Imagination Tech, apparently under some sort of NDA that prevents TI from publishing the details of this hardware. TI's only allowed to release a binary driver, that iwould require  creating its own infrastructure to work on BBB, and there's not enough interest in keeping up that work. What people would be interested in would be an open source driver, but IT and TI will not release information required for that, so there is no progress.

If you are interested in changing that, you could try to convince TI/IT to release information, and/or reverse engineer their driver.

[William Hermans]

I think it would be wise for the next iteration of the beaglebone, if there is one. That beagelbone.org uses a GPU that has open source drivers. Personally, for the most part. I could care less in the average everyday embedded type situation. But there has been times I've thought about making a mini MAME console, or the like; And we just can not do that with the beagelbone black.

So, I'd have to use an rPI, ODROID, etc. When I really would not want to.

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

or/and convince TI to move to Viviante for the 3d core. (the omap4/5
am57xx already have Vavante's 2d core..)

http://www.phoronix.com/scan.php?page=news_item&px=Vivante-Etnaviv-DRM-Driver

[Uvindu Silva]

TI specifies the capabilities of the 3359 GPU as follows,

• SGX530 3D Graphics Engine
  • Tile-Based Architecture Delivering up to 20 Million Polygons per second
  • Universal Scalable Shader Engine (USSE) is a Multithreaded Engine Incorporating Pixel and Vertex Shader Functionality
  • Advanced Shader Feature Set in Excess of Microsoft VS3.0, PS3.0, and OGL2.0
  • Industry Standard API Support of Direct3D Mobile, OGL-ES 1.1 and 2.0, OpenVG 1.0, and OpenMax
  • Fine-Grained Task Switching, Load Balancing, and Power Management
  • Advanced Geometry DMA-Driven Operation for Minimum CPU Interaction
  • Programmable High-Quality Image Anti-Aliasing
  • Fully Virtualized Memory Addressing for OS Operation in a Unified Memory Architecture

Now there are many features listed here. So how does TI expect a developer to use these features if there is no binary nor code support to talk to the GPU? Its actually confusing me.

I am a true lover of beaglebone and had been a very slow learning newbie about BBB for about two years now. In my level, I this is what I think;

TI enjoys a considerable amount of popularity with the help of the BBB open source community. Everyone in it may not have helped the development process, like I am, but helped the BBB community at least promoting it. I had promoted BBB without knowing this, as the matter of fact, none of the comparisons in the world take into the account that BBB has a GPU sitting there doing nothing. People try to compare the GPU of X board with with the BBBs GPU. 

When I asked about then about the AM335X GPU, they asked me to use a SOC from the OMAP series. That is a new architecture, who can be bothered to learn it? 

William reading, I think your point is really strong. rPI cannot currently be a headless system. But do you think there may be a way of manipulating things at the initialization level to minimize the resource allocation?

[Uvindu Silva]

I have one more question. Correct me if I am wrong, currently OpenGL ES 1.x/2.x is used to give support. Is that called a DRM? 

OpenGL is defiend as;

"OpenGL® ES is a low-level, lightweight API for advanced embedded graphics using well-defined subset profiles of OpenGL. It provides a low-level applications programming interface (API) between software applications and hardware or software graphics engines."

DRM is defined as;

"The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards. DRM exposes an API that user space programs can use to send commands and data to the GPU"

I believe DRM too offers a set of API to used with it through which user space programs can perform graphics processing.

To me it sounds like both OpenGL and DRM are doing similar jobs. I trust we have both OpenGL ES and DRM used in the BBB. So what exctly are the jobs of these two components? 

Please Help.

[Robert Nelson]

On Thu, Apr 9, 2015 at 8:11 PM, Uvindu Silva <IT120...@my.sliit.lk> wrote:
> TI specifies the capabilities of the 3359 GPU as follows,
>
> SGX530 3D Graphics Engine
>
> Tile-Based Architecture Delivering up to 20 Million Polygons per second
> Universal Scalable Shader Engine (USSE) is a Multithreaded Engine
> Incorporating Pixel and Vertex Shader Functionality
> Advanced Shader Feature Set in Excess of Microsoft VS3.0, PS3.0, and OGL2.0
> Industry Standard API Support of Direct3D Mobile, OGL-ES 1.1 and 2.0, OpenVG
> 1.0, and OpenMax
> Fine-Grained Task Switching, Load Balancing, and Power Management
> Advanced Geometry DMA-Driven Operation for Minimum CPU Interaction
> Programmable High-Quality Image Anti-Aliasing
> Fully Virtualized Memory Addressing for OS Operation in a Unified Memory
> Architecture
>
> Now there are many features listed here. So how does TI expect a developer
> to use these features if there is no binary nor code support to talk to the
> GPU? Its actually confusing me.

Here you go:

http://software-dl.ti.com/sitara_linux/esd/AM335xSDK/latest/index_FDS.html

It has "everything" TI's main customers want and full support of the am335x.

[William Hermans]

William reading, I think your point is really strong. rPI cannot currently be a headless system. But do you think there may be a way of manipulating things at the initialization level to minimize the resource allocation?

@Uvindu Silva

I've read a bunch of things. Technically, if you're capable of writing low level drivers, and understand the hardware really well; You can do anything. Me . . . I understand many things. One of these things I understand is that the more time I spend writing low level device drivers; The less time I spend on doing the things I really want to get done. Aside from the fact that this is really outside of what I currently know.

Would I like to instantly write drivers for x.y.z ? Sure . . . but I do not have the time, and still be able to get the things I want done. Plus, no one can know *everything*, and I am no exception. Like anyone else, I do the things I do best.

So, I spent half a day searching the web, looking for information on this matter, then decided it was not worth my time. So, perhaps *something* does exist, but I did not find it. Couple that with many other aspects of the hardware . . . and I just decided the rPI is not worth my time.

The rPI 2 on the other hand look more attractive from various points of view, but it also uses the same GPU . . . So for me personally. It would be a specific use case situation. A Case where the GPU would be used, and be very important for that use case.

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

On Thu, Apr 9, 2015 at 8:37 PM, Uvindu Silva <IT120...@my.sliit.lk> wrote:
> I have one more question. Correct me if I am wrong, currently OpenGL ES
> 1.x/2.x is used to give support. Is that called a DRM?
>
> OpenGL is defiend as;
>
> "OpenGL® ES is a low-level, lightweight API for advanced embedded graphics
> using well-defined subset profiles of OpenGL. It provides a low-level
> applications programming interface (API) between software applications and
> hardware or software graphics engines."
>
> DRM is defined as;
>
> "The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel
> responsible for interfacing with GPUs of modern video cards. DRM exposes an
> API that user space programs can use to send commands and data to the GPU"
> I believe DRM too offers a set of API to used with it through which user
> space programs can perform graphics processing.
>
>
> To me it sounds like both OpenGL and DRM are doing similar jobs. I trust we
> have both OpenGL ES and DRM used in the BBB. So what exctly are the jobs of
> these two components?

Well "similar" to the extent they are "abstraction" layers... Other
then that, totally different. (comparing apples and steak)

DRM: manages hardware
OpenGL: State Machine for generating graphics

[Robert Nelson]

> William reading, I think your point is really strong. rPI cannot currently
> be a headless system. But do you think there may be a way of manipulating
> things at the initialization level to minimize the resource allocation?

Why not "headless"? Just don't plug the video in. That's the
definition of "headless"..

[William Hermans]

Why not "headless"? Just don't plug the video in. That's the
definition of "headless"..

This is why i said technically Robert. You're wasting system resources, for something you're not using.

Anyway, it detracts from the SBC in my mind. Then thinking about many other things like, no PRU, 16-26 IO pins, no "real" distro support . . .

The list just keeps on growing, and growing, the more you look into it.

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[William Hermans]

SO yes, the same difference with a PC. If you're using an integrated GPU that allocates system memory at the BIOS level. However, the BBB does not have this problem.

[Robert Nelson]

On Thu, Apr 9, 2015 at 9:22 PM, William Hermans <yyr...@gmail.com> wrote:

Why not "headless"? Just don't plug the video in. That's the
definition of "headless"..

This is why i said technically Robert. You're wasting system resources, for something you're not using.

Anyway, it detracts from the SBC in my mind. Then thinking about many other things like, no PRU, 16-26 IO pins, no "real" distro support . . .

The list just keeps on growing, and growing, the more you look into it.

See, we actually steal some memory with the kernel on the bbb too, via CMA but usually around 16Mb -> 24Mb. So it's not as drastic as the Pi. (they have multiple options for the bootloader, based on resolution)

Adding, "cma=0" will let you re-coop that on the bbb ;)

Regards,

[William Hermans]

Adding, "cma=0" will let you re-coop that on the bbb ;)

kernel parameter ?

One thing I did notice though is that the TI kernels use around that much less memory . . . and I was not sure why ( I did not look deep into it ) Perhaps this is why ?  Let me find my notes.

--

[Robert Nelson]

On Thu, Apr 9, 2015 at 9:29 PM, William Hermans <yyr...@gmail.com> wrote:

Adding, "cma=0" will let you re-coop that on the bbb ;)

kernel parameter ?

correct..

 

One thing I did notice though is that the TI kernels use around that much less memory . . . and I was not sure why ( I did no

Yeah, in 3.14.x-ti it's defaulted to 24Mb

#

# Default contiguous memory area size:

#

CONFIG_CMA_SIZE_MBYTES=24

CONFIG_CMA_SIZE_SEL_MBYTES=y

# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set

# CONFIG_CMA_SIZE_SEL_MIN is not set

# CONFIG_CMA_SIZE_SEL_MAX is not set

CONFIG_CMA_ALIGNMENT=8

CONFIG_CMA_AREAS=7

Before that it was usually 16Mb, according to their notes, it was mostly for sgx and bigger resolutions..

Regards,

[William Hermans]

bone-debian-7.7-console-armhf-2014-11-19-2gb.img
pstree
systemd-+-2*[agetty]
        |-cron
        |-rsyslogd---3*[{rsyslogd}]
        |-sshd---sshd---sshd---bash---pstree
        |-systemd-journal
        `-udevd---2*[udevd]

Ah wonderful. This must really be Jessie as Wheezy typically has "init" as the first process. Searching the web quickly however shows debian 7.7 as Wheezy - So whatever . . . No problem, this just means I need to do more research if anything requires systemd-isms. At any rate we can see that there is not a huge amount of resources being used up.

About my comment here. Ever get so focused on a "thing" that you overlook the obvious ? Link to the Filename had Jessie in it . . .

free
             total       used       free     shared    buffers     cached
Mem:        508448      97824     410624          0      20180      36984
-/+ buffers/cache:      40660     467788
Swap:            0          0          0

sudo apt-get -o Acquire::http::Dl-Limit=40 install linux-image-3.14.26-ti-r39

pstree
systemd-+-2*[agetty]
        |-cron
        |-rsyslogd---3*[{rsyslogd}]
        |-sshd---sshd---sshd---bash---pstree
        |-systemd-journal
        `-udevd---2*[udevd]

free
             total       used       free     shared    buffers     cached
Mem:        498408      45836     452572          0       3572      12760
-/+ buffers/cache:      29504     468904
Swap:            0          0          0

First thing that came to my own mind was that perhaps TI was using less, or possibly no RAM disk . . .

[Robert Nelson]

On Thu, Apr 9, 2015 at 9:39 PM, William Hermans <yyr...@gmail.com> wrote:

bone-debian-7.7-console-armhf-2014-11-19-2gb.img
pstree
systemd-+-2*[agetty]
        |-cron
        |-rsyslogd---3*[{rsyslogd}]
        |-sshd---sshd---sshd---bash---pstree
        |-systemd-journal
        `-udevd---2*[udevd]

Ah wonderful. This must really be Jessie as Wheezy typically has "init" as the first process. Searching the web quickly however shows debian 7.7 as Wheezy - So whatever . . . No problem, this just means I need to do more research if anything requires systemd-isms. At any rate we can see that there is not a huge amount of resources being used up.

About my comment here. Ever get so focused on a "thing" that you overlook the obvious ? Link to the Filename had Jessie in it . . .

All the time!

For wheezy, systemd was optional, but check your /proc/cmdline, we've been forcing systemd as init. ;)

 

free
             total       used       free     shared    buffers     cached
Mem:        508448      97824     410624          0      20180      36984
-/+ buffers/cache:      40660     467788
Swap:            0          0          0

sudo apt-get -o Acquire::http::Dl-Limit=40 install linux-image-3.14.26-ti-r39

pstree
systemd-+-2*[agetty]
        |-cron
        |-rsyslogd---3*[{rsyslogd}]
        |-sshd---sshd---sshd---bash---pstree
        |-systemd-journal
        `-udevd---2*[udevd]

free
             total       used       free     shared    buffers     cached
Mem:        498408      45836     452572          0       3572      12760
-/+ buffers/cache:      29504     468904
Swap:            0          0          0

First thing that came to my own mind was that perhaps TI was using less, or possibly no RAM disk . . .

I don't think 'free' shows cma yet... So you'll have to judge it from:

dmesg | grep cma

cat /proc/meminfo | grep Cma

free -lh

Regards,

[William Hermans]

For wheezy, systemd was optional, but check your /proc/cmdline, we've been forcing systemd as init. ;)

Duh !!! Why didn't i think of that? FFS its only in uENV.txt as: init= blahbahblah/systemd . . . Two obvious things overlooked . . .

--

[William Hermans]

@Robert,

Can I assume, even with the newest of 3.8.x image, that I can comment out the:

init=<whatever>

Line, and default back to init ? This is sometime I had not even thought to experiment with yet. This whole time I had been avoiding your new images because I did not really want to invest time into understanding systemd *yet*.

[William Hermans]

sometime == something . . .and sorry for hijacking the thread.

[Robert Nelson]

On Thu, Apr 9, 2015 at 9:59 PM, William Hermans <yyr...@gmail.com> wrote:
> @Robert,
>
> Can I assume, even with the newest of 3.8.x image, that I can comment out
> the:
>
> init=<whatever>
>
> Line, and default back to init ? This is sometime I had not even thought to
> experiment with yet. This whole time I had been avoiding your new images
> because I did not really want to invest time into understanding systemd
> *yet*.

Yeap, in wheezy in "uEnv.txt" just remove "init=/lib/systemd/systemd"
and it'll default to classic init.

[William Hermans]

Thanks Robert :)

[Uvindu Silva]

thank you people for your responses.

I contacted TI to question about this issue. The responses you may have expected was not at all good. It is sad indeed. Although I was told that the TI SDK supports the GPU and it is compatible with the BBB. So,  I guess a person who really wants to test the power of the GPU may use the TI SDK with the binary blobs.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/NhiiScKy7eU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Uvindu Silva]

Although I raised the question about their future plans about incorporating the GPU Robert suggested, it was not responded. I guess they sure wouldn't inform their plans to us.