Embedded Intel Atom® Processors
Technological Conversations about Intel Atom® Hardware, Software, Firmware, Graphics

buffer class driver for EMGD



I'm currently creating a buffer class driver for EMGD based on

the source code found in emgd_bc.c (available in the Linux

package). This driver creates different devices /dev/bccat0,

/dev/bccat1, etc. and allows the user to mmap these devices.

My goal is to allow user-space applications to directly access

texture data with the texture streaming extensions.

So far the driver loads correctly and is also able to allocate

buffers from ioctls calls (I used the same recipe found in

emdg_bc.c and also from other drivers available on other

platforms using PowerVR GPUs).

Now the problem I'm having is that each call to

glGetTexStreamDeviceNameIMG always returns a NULL pointer with GL

error 1281.

First question: Is what I'm trying to acheive here possible? I

mean, is the EMGD driver capable of doing texture streaming with

my approach?

Second question: Is there any info available on how to actually

use the PowerVR kernel API?



0 Kudos
1 Reply
Valued Contributor I

Hi Marc

Intel's EMDG expert Kirk Blum asked me to pass along this reply (he was having some technical issue accessing the site)...

From Kirk -

Let me answer your last question first as it has bearing on the first question.

The IP contained in the PowerVR is very carefully licensed by the owner and greatly restricts the information we can make available. What we have released in source code in the EMGD package is everything that we are allowed to release including information on the APIs used.

As such, the specific calls, even though exposed in the kernel code, the inner workings are still considered private by the IP owner (and is the reason they run in User space, not the Linux kernel).

I think you are getting the idea about the first question- I just do not have anything that we can provide on how that specific call works. It may actually be a generic item in a standard PowerVR header but is not "wired up" inside the driver. It is also subject to change so if you managed to figure out how it works, there is a really good chance it would change in the future.

From my experience, your idea is very elegant, but may be trying to be "too cleaver". If I am not mistaken, there are other ways to stream textures that will work through more standard calls and you probably should be looking for those..

I hope this helps



J. Felix McNulty

Community Moderator (Intel contractor)

0 Kudos