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 Thomas Martitz - 2009-06-03
Last edited by Rafaël Carré - 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  Rafaël Carré
2009-09-30 18:54
Reason for closing:  Accepted
Additional comments about closing:  

r22859

Bertrik Sikken commented on 2009-06-03 19:22

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

Dustin Skoracki 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.

Thomas Martitz commented on 2009-06-03 22:06

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

Thomas Martitz commented on 2009-06-03 22:18

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

No blue bars :) No apparent display corruption.

Dustin Skoracki 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.

Thomas Martitz commented on 2009-06-03 22:49

What are the exact numbers?

Matt M commented on 2009-06-04 07:08

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

Dustin Skoracki 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  .

Dustin Skoracki 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.

Bertrik Sikken commented on 2009-06-04 21:38

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.

Rafaël Carré commented on 2009-06-07 23:28

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

Thomas Martitz commented on 2009-06-09 00:06

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.

Thomas Martitz commented on 2009-08-31 17:47

Can some e200v2 owner test this?

Thomas Martitz commented on 2009-08-31 17:56

and this one too please.

Thomas Martitz commented on 2009-08-31 23:12

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

Michael Chicoine commented on 2009-09-01 12:28

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.

Thomas Martitz commented on 2009-09-01 14:08

Can you try if reverting to r22577 fixes anything?

Michael Chicoine commented on 2009-09-01 18:53

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.

Thomas Martitz commented on 2009-09-01 19:11

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.

Michael Chicoine commented on 2009-09-12 18:11

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.

Michael Chicoine commented on 2009-09-20 07:20

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

Thomas Martitz commented on 2009-09-20 09:57

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

Michael Chicoine commented on 2009-09-21 01:59

Here is a patch to fix the e200v2.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing