i.MX28 Data Co-processor (DCP) Blit Copy/Fill Driver

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

i.MX28 Data Co-processor (DCP) Blit Copy/Fill Driver

1,608 次查看
JamesAttewell
Contributor I
Hi All,

Has anyone written a Linux driver for the MX28 Data Co-processor (DCP) to handle Blit copies and fills?

Or can anyone recommend a good driver to use as a template for this?

Freescale provide a driver to use the DCP in the Crypto API but I want to use it to speed up the graphics operations I am doing...

Cheers

James

标签 (1)
0 项奖励
7 回复数

1,035 次查看
RobertSchwebel
Contributor IV

Our expierience is: if blitting is provided by the kernel, you need additional context switches, which eat up the improvements quickly. In other settings the CPU often waits until the blitter engine is finished, which doesn't win anything as well. Even modern acceleration technologies based on OpenGL at least need really new Qt versions, and even then it depends on what you are doing, if it is widget of scenegraph based etc.

In conclusion, I wouldn't expect too much. However, if you like, you can try it and report the benchmark results here. It would be interesting to see what can be achieved.

rsc

0 项奖励

1,035 次查看
sidebranch
Contributor II

Robert,

can you explain why it wouldn't help? From what I read in the Qt documentation, Qt draws and updates each widget in a private buffer, then needs a blit to the main framebuffer, so I would expect a custom Qt driver to be accelerated by such blit in hardware.

Leon.

0 项奖励

1,035 次查看
RobertSchwebel
Contributor IV

No, because it wouldn't help for the "usual" standard frameworks like Qt, web etc.

rsc

0 项奖励

1,035 次查看
JamesAttewell
Contributor I

Hi Robert,

I have looked at Qt and it has some nice features but it is too heavy weight for us and also probably too complicated for our customers. I wasnt going to embark on a lot of DCP driver work without fully evaluating the impact it would have on whichever framework we eventually go with, I was just exploring the options and wanted to know if anyone had used the blit functionality of the DCP and already had a driver working.

Obviously OpenGL won't be any use without the hardware, I meant I would have to remove OpenGL from SMFL and replace it with an alternative using software based rendering. The plan would then be to implement a simple GUI framework that meets our requirements on top of SMFL.

Have you used the DCP for blitting/filling at all (or anyone else for that matter)? How does it compare speed wise to using a software based solution?

James

0 项奖励

1,035 次查看
RobertSchwebel
Contributor IV

Not really (we usually use Qt), but you should decide about a framework before optimizing with DCP. Most frameworks do not necessarily make use of simple acceleration features.

OpenGL won't help without a hardware unit.

rsc

0 项奖励

1,035 次查看
JamesAttewell
Contributor I

Hi Robert,

We haven't selected a framework as yet, this would be for a completely new version of our SDK. I have looked at many of them. I like SMFL but this is OpenGL based and would need some custom work done on it to replace these OpenGL calls to make it a viable option.

Do you have any recommendations?

James

0 项奖励

1,035 次查看
RobertSchwebel
Contributor IV

James,

what do you want to do ontop of that driver? Our experience is that possible performance improvments highly depend on the framework backend infrastructure you are using. So which graphics framework are you intending to use?

rsc

0 项奖励