GStreamer DSP test

[hdonk]

I've uploaded a PND to the repo, which is a basic test of playing back video on the DSP.

http://repo.openpandora.org/?page=detail&app=gst_dsp_pkg

The pnd will ask for your password.

WARNING: Installing this PND can hose your system, as it changes the kernel & modules. Try it out on an SD installation of SZ first.

If you still want to try it, fire up the PND, install everything, reboot your pandora, and fire up the pnd again.

Pull a test video from the net:

wget http://ie.microsoft.com/testdrive/graphics/videoformatsupport/big_buck_bunny_trailer_480p_baseline.mp4

Then play it:

gst-launch playbin2 uri=file:///absolute/path/to/big_buck_bunny_trailer_480p_baseline.mp4

If you want to encode your own version of the full thing, on a PC with ffmpeg & libx264 installed:

wget http://mirror.bigbuckbunny.de/peach/bigbuckbunny_movies/big_buck_bunny_720p_stereo.avi

 ffmpeg -i big_buck_bunny_720p_stereo.avi -s 854x480 -c:v libx264 -preset slow -profile:v baseline -b:v 1000k -c:a copy bbb.mp4

If something goes wrong, and the dsp appears hosed, used the dsp command which reloads the dsp modules.

dsp

There is also a copy of iotop, and the kernel has thread metrics compiled in to support it.

sudo bin/iotop.py

If this works well enough for people, I'll fire over the changes needed to the kernel to ED so this should end up much less intrusive.

Good luck!

 

 

[Linux-SWAT]

Is it possible to know more about kernel changes ?

 

[hdonk]

Of course:

Enabled:

TASK_DELAY_ACCT CONFIG_TASKSTATS, TASK_IO_ACCOUNTING and CONFIG_VM_EVENT_COUNTERS

and added:

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index f9adbbb..2dfb2da 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -80,9 +80,9 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32 reg,
 
 static void omap_timer_restore_context(struct omap_dm_timer *timer)
 {
-    omap_dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_OFFSET,
-                timer->context.tiocp_cfg);
-    if (timer->revision > 1)
+       __raw_writel(timer->context.tiocp_cfg,
+                       timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
+       if (timer->revision == 1)
         __raw_writel(timer->context.tistat, timer->sys_stat);
 
     __raw_writel(timer->context.tisr, timer->irq_stat);
@@ -357,6 +357,21 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
 
     __omap_dm_timer_stop(timer, timer->posted, rate);
 
+       if (timer->loses_context) {
+               if (timer->get_context_loss_count)
+                       timer->ctx_loss_count =
+                       timer->get_context_loss_count(&timer->pdev->dev);
+       }
+
+       /*
+        * Since the register values are computed and written within
+        * __omap_dm_timer_stop, we need to use read to retrieve the
+        * context.
+        */
+       timer->context.tclr =
+                       omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
+       timer->context.tisr = __raw_readl(timer->irq_stat);
+       omap_dm_timer_disable(timer);
     return 0;
 }
 EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
 

 

[notaz]

There is a kernel update coming up slowly, and it will break your .pnd, so I ask some questions:

Enabled:

TASK_DELAY_ACCT CONFIG_TASKSTATS, TASK_IO_ACCOUNTING and CONFIG_VM_EVENT_COUNTERS

These are for iotop only, right? I was kind of worried they may have performance impact.

and added:

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c

index f9adbbb..2dfb2da 100644

--- a/arch/arm/plat-omap/dmtimer.c

+++ b/arch/arm/plat-omap/dmtimer.c

@@ -80,9 +80,9 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32 reg,

...

Where did this come from and why is it needed?

 

[hdonk]

There is a kernel update coming up slowly, and it will break your .pnd, so I ask some questions:

Enabled:


TASK_DELAY_ACCT CONFIG_TASKSTATS, TASK_IO_ACCOUNTING and CONFIG_VM_EVENT_COUNTERS

These are for iotop only, right? I was kind of worried they may have performance impact.

and added:


diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c


index f9adbbb..2dfb2da 100644


--- a/arch/arm/plat-omap/dmtimer.c


+++ b/arch/arm/plat-omap/dmtimer.c


@@ -80,9 +80,9 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32 reg,


...

Where did this come from and why is it needed?

I'm not sure how a kernel upgrade will break my PND as it contains it own kernel!

The options will of course have a slight performance impact. But iotop is just too useful to me for diagnosis when things grind to a halt.

The patch came from the web, and I had no luck getting the DSP working without it. You are welcome to try tho

This looks like the source:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58337.html

 

[freamon]

It took me a few attempts to get this working.

Firstly, my autostart.txt was pointing directly to uImage-3, rather than the uImage symlink, so rebooting didn't load your kernel.

Secondly, I didn't realise I was supposed to start the PND again and so tried to play the file from a normal command line. It's worth noting though, that your PND just calls 'dsp', not 'gksudo dsp', so it fails, and I needed to type 'dsp' and then my password to get it working.

Because I tried to play it so many times without the DSP, I could see the difference it makes when it *is* using it. However, it still seems to use 95% cpu (vs. 60% for smplayer2 on the same file).

 

[hdonk]

It took me a few attempts to get this working.Firstly, my autostart.txt was pointing directly to uImage-3, rather than the uImage symlink, so rebooting didn't load your kernel.Secondly, I didn't realise I was supposed to start the PND again and so tried to play the file from a normal command line. It's worth noting though, that your PND just calls 'dsp', not 'gksudo dsp', so it fails, and I needed to type 'dsp' and then my password to get it working.Because I tried to play it so many times without the DSP, I could see the difference it makes when it *is* using it. However, it still seems to use 95% cpu (vs. 60% for smplayer2 on the same file).

The DSP script does sudo the commands tho...
As I said this is purely a test to get some DSP love out there. I'm not surprised that the cpu utilization is up as there's been no optimization done... I wonder where the bottleneck is...


And at least it does work for someone else. Yay


Thanks for testing!

 

[Zero3K]

1. How do I undo what the PND did?

2. It caused the Pandora to not be able to detect and use the mini NETGEAR Network Adapter I have plugged in when I enable USB Host mode.

 

[Wally]

Reflash.

1. How do I undo what the PND did?

2. It caused the Pandora to not be able to detect and use the mini NETGEAR Network Adapter I have plugged in when I enable USB Host mode.

 

[hdonk]

1. How do I undo what the PND did?


2. It caused the Pandora to not be able to detect and use the mini NETGEAR Network Adapter I have plugged in when I enable USB Host mode.

cd /boot
sudo rm uImage


sudo ln -s uImage-3 uImage

 

[notaz]

The patch came from the web, and I had no luck getting the DSP working without it. You are welcome to try tho

This looks like the source:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58337.html

Thanks for the info. Still not sure if I should enable iotop statistics in default kernel..

 

[hdonk]

The patch came from the web, and I had no luck getting the DSP working without it. You are welcome to try tho This looks like the source:http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58337.html

Thanks for the info. Still not sure if I should enable iotop statistics in default kernel..

Its easy enough for those of us working on apps to build our own kernels, so if you're even vaguely concerned about the performance impact from these metrics then don't enable them! I just listed them as I was asked what changes I made in the kernel I put in the pnd. Also as I stated this is just a test to see if it works for other people, and if it's worth taking further, and for that I felt iotop might be useful.

 

[EvilDragon]

Ah, so iotop is not needed for the DSP, but currently helpful for finding issues, right?

Neat, then it seems we can finally make use of the DSP as well soon

 

[ekianjo]

It took me a few attempts to get this working.


Firstly, my autostart.txt was pointing directly to uImage-3, rather than the uImage symlink, so rebooting didn't load your kernel.


Secondly, I didn't realise I was supposed to start the PND again and so tried to play the file from a normal command line. It's worth noting though, that your PND just calls 'dsp', not 'gksudo dsp', so it fails, and I needed to type 'dsp' and then my password to get it working.


Because I tried to play it so many times without the DSP, I could see the difference it makes when it *is* using it. However, it still seems to use 95% cpu (vs. 60% for smplayer2 on the same file).

What kind of difference does it make when you watch the video ? Does it seem smoother or something ? 

Is there any remote possibility that videos with larger resolution could benefit from this in the future ?

 

[notaz]

1. How do I undo what the PND did?

2. It caused the Pandora to not be able to detect and use the mini NETGEAR Network Adapter I have plugged in when I enable USB Host mode.

cd /bootsudo rm uImage

sudo ln -s uImage-3 uImage

BTW recent firmwares boot uImage-3 directly by default, not uImage.

 

[notaz]

Got it to work, however it only works on your kernel+modules, but not with mine, even with patch applied:

[  221.944061] memory_regain_ownership: dma info doesn't match given params
[  221.951110] proc_end_dma: InValid address parameters 00381380 680

So any other kernel/tidspbridge changes? Something else different in .config?

 

[hdonk]

Got it to work, however it only works on your kernel+modules, but not with mine, even with patch applied:

[  221.944061] memory_regain_ownership: dma info doesn't match given params
[  221.951110] proc_end_dma: InValid address parameters 00381380 680

So any other kernel/tidspbridge changes? Something else different in .config?

I'll run a diff on the .config files later. It's possible i 've got other build options set...

 

[freamon]

Because I tried to play it so many times without the DSP, I could see the difference it makes when it *is* using it. However, it still seems to use 95% cpu (vs. 60% for smplayer2 on the same file).

What kind of difference does it make when you watch the video ? Does it seem smoother or something ? Is there any remote possibility that videos with larger resolution could benefit from this in the future ?

Trying to watch the video using the normal gstreamer codecs produced stuttering video, and an error on the command line that it was needing to drop frames and that my computer was too slow. Playing it using the dsp produced smooth video, and no errors.

It's not something I know much about, but I'm fairly sure that the DSP can only decode baseline profile MP4s, which typically isn't the kind of thing anybody would use to encode hi-res video. I think that the main potential future benefit of utilising the DSP is that if you can offload video/audio decoding to it, it would free up your CPU for other stuff, rather than it enabling us to watch higher quality videos than we can now.

 

[hdonk]

Here's the .config diffs. Forgot about the MMU stuff


--- op-config    2013-02-20 08:06:56.000000000 +0000
+++ hd-config    2013-02-20 08:06:39.000000000 +0000
@@ -36,7 +36,7 @@
  CONFIG_BROKEN_ON_SMP=y
 CONFIG_INIT_ENV_ARG_LIMIT=32
 CONFIG_CROSS_COMPILE=""
-CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION="hdonk"
  CONFIG_LOCALVERSION_AUTO=y
  CONFIG_HAVE_KERNEL_GZIP=y
  CONFIG_HAVE_KERNEL_LZMA=y
@@ -53,7 +53,10 @@
  CONFIG_BSD_PROCESS_ACCT=y
  # CONFIG_BSD_PROCESS_ACCT_V3 is not set
 # CONFIG_FHANDLE is not set
-# CONFIG_TASKSTATS is not set
+CONFIG_TASKSTATS=y
+CONFIG_TASK_DELAY_ACCT=y
+CONFIG_TASK_XACCT=y
+CONFIG_TASK_IO_ACCOUNTING=y
 # CONFIG_AUDIT is not set
  CONFIG_HAVE_GENERIC_HARDIRQS=y
  @@ -2901,8 +2904,11 @@
  # Hardware Spinlock drivers
 #  CONFIG_CLKSRC_MMIO=y
+CONFIG_IOMMU_API=y
  CONFIG_IOMMU_SUPPORT=y
-# CONFIG_OMAP_IOMMU is not set
+CONFIG_OMAP_IOMMU=y
+CONFIG_OMAP_IOVMM=y
+CONFIG_OMAP_IOMMU_DEBUG=y
 # CONFIG_VIRT_DRIVERS is not set
 CONFIG_PM_DEVFREQ=y

Edit: Fixed layout

 

[ekianjo]

It's not something I know much about, but I'm fairly sure that the DSP can only decode baseline profile MP4s, which typically isn't the kind of thing anybody would use to encode hi-res video. I think that the main potential future benefit of utilising the DSP is that if you can offload video/audio decoding to it, it would free up your CPU for other stuff, rather than it enabling us to watch higher quality videos than we can now.

I see, thanks for the thorough answer! I now remember about the MP4 baseline discussion before. 

When you say "offload video/audio" decoding to the DSP, do you have any particular idea of what applications may benefit from it then ? Audio players ? Emulators (not sure if it applies here) ? Others?