Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Drivers
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.2
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by kugel. - 2009-06-03
Last edited by funman - 2009-09-30

FS#10272 - Sansa AMS: lcd driver speed up

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.

Closed by  funman
2009-09-30 18:54
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

r22859

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

sko commented on 2009-06-03 22:01

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.

Interesting. So I'd say with 100fps we really hit the limit of the hardware. A bit sad, 100fps isn't that much.

2832 (585 grey) 3543.5 (1600 grey) with my patch on my clip.

No blue bars :) No apparent display corruption.

sko commented on 2009-06-03 22:22

I tried it on my e250v2 without  FS#10048  and could not see any blue bars, so it seems related to the mmu stuff.

What are the exact numbers?

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

sko commented on 2009-06-04 07:37

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

sko commented on 2009-06-04 08:31

- "What are the exact numbers?"

Sorry, I missed the comment. Without mmu I get 61.5 fps unboosted and 94.0 fps boosted.

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.

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

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.

Can some e200v2 owner test this?

and this one too please.

Just test this, it's a sync of the lcd-speedup.diff. e200v2-only-speedup-.diff has been committed.

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.

Can you try if reverting to r22577 fixes anything?

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.

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.

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.

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().

I've fixed it on the fuze (r22627), please have a look into porting the fixes to the e200v2 and post a patch.

Here is a patch to fix the e200v2.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing