Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/rockbox.org/flyspray/adodb/adodb.inc.php on line 845 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.user.php on line 111 FS#10272 : Sansa AMS: lcd driver speed up

Rockbox

Tasklist

FS#10272 - Sansa AMS: lcd driver speed up

Attached to Project: Rockbox
Opened by Thomas Martitz (kugel.) - Wednesday, 03 June 2009, 17:22 GMT
Last edited by Rafaël Carré (funman) - Wednesday, 30 September 2009, 18:54 GMT
Task Type Patches
Category Drivers
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This vastly improves the lcd_write_data() performance on my fuze (from <50fps to 90fps unboosted [numbers with  FS#10048  appled) by filling the FIFO to full and using an interrupt to detect that it is full.

I'm getting blue bars on the screen if lcd updates are happening when boosted, this however might be due to  FS#10048  applied.

Weird: I can't get above exact 100.0 fps with boosted. We either hit the maximum of the FIFO or miss some bits in the Fuze's LCD initialization.

Please try to adapt for e200v2 (and others) and report numbers.
   lcd-speedup.diff (3 KiB)
This task depends upon

Closed by  Rafaël Carré (funman)
Wednesday, 30 September 2009, 18:54 GMT
Reason for closing:  Accepted
Additional comments about closing:  r22859
Comment by Bertrik Sikken (bertrik) - Wednesday, 03 June 2009, 19:22 GMT
Here's my patch with the same idea, a lot simpler and probably slightly slower. I get about 30% speedup from this on my clip (haven't tested it on fuze, because I don't have one).
   ams_dbop_fifo.patch (1.2 KiB)
Comment by Dustin Skoracki (sko) - Wednesday, 03 June 2009, 22:01 GMT
Here is kugels patch with e200v2: also 90 fps unboosted, but not more than 100.0 fps boosted. I have also blue bars when boosted like kugel wrote, but I have  FS#10048  applied, too.
   lcd-speedup_with_e200v2.diff (4.9 KiB)
Comment by Thomas Martitz (kugel.) - Wednesday, 03 June 2009, 22:06 GMT
Interesting. So I'd say with 100fps we really hit the limit of the hardware. A bit sad, 100fps isn't that much.
Comment by Thomas Martitz (kugel.) - Wednesday, 03 June 2009, 22:18 GMT
2832 (585 grey) 3543.5 (1600 grey) with my patch on my clip.

No blue bars :) No apparent display corruption.
Comment by Dustin Skoracki (sko) - Wednesday, 03 June 2009, 22:22 GMT
I tried it on my e250v2 without  FS#10048  and could not see any blue bars, so it seems related to the mmu stuff.
Comment by Thomas Martitz (kugel.) - Wednesday, 03 June 2009, 22:49 GMT
What are the exact numbers?
Comment by Matt M (Chesteta) - Thursday, 04 June 2009, 07:08 GMT
I am getting the blue bars also on my e280v2; I applied this patch first, then the latest ams-caching.diff patch (posted: by Rafaël Carré (funman) - Wednesday, 03 June 2009, 13:15 GMT+2) the blue bars only show up when changing songs or doing 'system intensive' things

I noticed that if I apply this patch first (to a clean checkout) then the ams-caching, there is no error (but blue bars) but when applying the caching patch and then this patch, there was some error about one of the files already being patched (yes I know it would be helpful to know what files but the log has already past that part, sorry)... using r21184
Comment by Dustin Skoracki (sko) - Thursday, 04 June 2009, 07:37 GMT
- "when applying the caching patch and then this patch, there was some error about one of the files already being patched"

Right, there was one change in system_as3525.c (#include mmu.h) which is in both patches, here is a patch without it as it is related to  FS#10048  .
   lcd-speedup_with_e200v2_b.diff (4.7 KiB)
Comment by Dustin Skoracki (sko) - Thursday, 04 June 2009, 08:31 GMT
- "What are the exact numbers?"

Sorry, I missed the comment. Without mmu I get 61.5 fps unboosted and 94.0 fps boosted.
Comment by Bertrik Sikken (bertrik) - Thursday, 04 June 2009, 21:38 GMT
I committed the simple DBOP FIFO fix for clip. Even though the frame-per-second for clip is not really a problem, this gives a nice speedup with low complexity.
Comment by Rafaël Carré (funman) - Sunday, 07 June 2009, 23:28 GMT
The interrupts bits don't need to be cleared in the isr (according to the datasheet)

Also I think it would be nice to have each bits defined with their names
Comment by Thomas Martitz (kugel.) - Tuesday, 09 June 2009, 00:06 GMT
Bertrik, I just tried your patch again after the MMU patch commit.

Unboosted, my patch is by far faster. 64.5fps vs 90fps
Boosted, both patches reach 100fps, and both show blue bars.
Comment by Thomas Martitz (kugel.) - Monday, 31 August 2009, 17:47 GMT
Can some e200v2 owner test this?
   lcd-speedup.diff (2.4 KiB)
Comment by Thomas Martitz (kugel.) - Monday, 31 August 2009, 17:56 GMT
and this one too please.
   e200v2-only-speedup-.diff (4.3 KiB)
Comment by Thomas Martitz (kugel.) - Monday, 31 August 2009, 23:12 GMT
Just test this, it's a sync of the lcd-speedup.diff. e200v2-only-speedup-.diff has been committed.
   lcd-speedup.diff (1.7 KiB)
Comment by Michael Chicoine (mc2739) - Tuesday, 01 September 2009, 12:28 GMT
On my e200v2, I am seeing very intermittent blue pixels with latest svn (r22588).

Also, the splashes are sometimes skewed. This is most notable when using a larger font than the one with the default cabbiev2 theme (I use the widecabbie theme). It is very reproducible with the opening splash for the doom plugin.
Comment by Thomas Martitz (kugel.) - Tuesday, 01 September 2009, 14:08 GMT
Can you try if reverting to r22577 fixes anything?
Comment by Michael Chicoine (mc2739) - Tuesday, 01 September 2009, 18:53 GMT
I have not seen any blue pixels with r21577, but I still see the skewed splashes as described above. The splashes are correct if I revert back to r22574.
Comment by Thomas Martitz (kugel.) - Tuesday, 01 September 2009, 19:11 GMT
The blue pixels (btw, I explicitely asked you about those in IRC :p ) probably go away if you increase the button_delay (a #define in button-e200v2-fuze.c) a bit.
Comment by Michael Chicoine (mc2739) - Saturday, 12 September 2009, 18:11 GMT
I have also noticed distortion in mpegplayer progress bar. To reproduce, start a video, pause the video, resume the video. As with the splash distortion, the started with r22575 and was fine with r22574.
Comment by Michael Chicoine (mc2739) - Sunday, 20 September 2009, 07:20 GMT
After further testing, I have determined that the skew/distortion is happening in lcd_update_rect(). This was verified by bypassing the lcd_update_rect() code with a call to lcd_update().
Comment by Thomas Martitz (kugel.) - Sunday, 20 September 2009, 09:57 GMT
I've fixed it on the fuze (r22627), please have a look into porting the fixes to the e200v2 and post a patch.
Comment by Michael Chicoine (mc2739) - Monday, 21 September 2009, 01:59 GMT
Here is a patch to fix the e200v2.
   lcd-e200v2-fix.diff (1.2 KiB)

Loading...