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

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.

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,

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.

Feel free to contact TI directly on that issue.

Regards,

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.

Regards,

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?

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.

Regards,

Thank you Robert for your time.

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 <https://en.wikipedia.org/wiki/PowerVR#Series_5>
<https://en.wikipedia.org/wiki/BeagleBoard#cite_note-32> 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.

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.

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.

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

Regards,

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?

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.

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.

Regards,

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.

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

Regards,

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

Regards,

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.