Hi,
I was able to get rid of the L3 errors when using TILER 2D buffer. Patch attached. It's illegal to use caching on TILER 2D buffers, so that was causing the issues.
As for the Pyra, my main recommendation is still the same: if you more or less always want landscape oriented picture, get a landscape oriented LCD. That will avoid huge amounts of much trouble. Believe me, I've worked with the similar issues since omap2 times =).
But I understand that may not be an option. So, about TILER. I still believe it is possible to use TILER for this. The main problem with the performance issues seen is the design of the tiler code in omapdrm. It has not been designed with CPU access in mind.
What it does currently is that instead of memory mapping the whole TILER buffer, as one would do for a normal buffer, it only uses two pages, which it will remap using page faults.
This pretty much kills the performance if you do random single pixel accesses all around the buffer. It'll take minutes to go through the full 1020p frame. Of course, that gives you very bad performance even with normal buffers, so it's not a realistic use case.
Using memcpy to read/write a full line from the tiler buffer gives better performance, but it's still not very good. Probably not even good enough to be usable.
So, what can be done.
If the CPU is used to draw the frame, and it's likely that the CPU will also read from the frame, and write non-sequentially, I think it's clear that a separate back buffer needs to be used. The back buffer can be mmaped to cpu normally, with full caching. After the drawing is done, caches have to be flushed, and then the buffer can be copied to the TILER buffer.
It could be that the omap xorg driver already does this (or maybe not, no idea). X does have shadow buffer stuff there, which I think does something like that.
However, as I said above, with my testing the memcpy is still on the slow side, so even the back buffer may not be fast enough.
I see a few ways to make the copying faster:
- Optimize the current mmapping code (I don't know if there's anything to optimize, though)
- Add support to omapdrm to mmap the whole tiler buffer. I think this should be doable, but it will waste more tiler space which the current code is trying to avoid.
- Use system DMA to do the copy. I don't know what the performance difference with copying with sDMA and CPU is for normal buffers, but in this case using sDMA would avoid the whole mmapping issue totally. (Actually, the copying could maybe also be done with DSP, SGX or any other HW component that supports mem copying, but sDMA is perhaps the easiest).
Tomi
Hi,
Nice, thanks for figuring it out.
On Tue, Apr 1, 2014 at 9:58 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
I was able to get rid of the L3 errors when using TILER 2D buffer. Patch attached. It's illegal to use caching on TILER 2D buffers, so that was causing the issues.
Hmm, that was write combining, not caching. Shame even that doesn't work, accessing strongly ordered memory will be very slow even if the page fault problem is fixed.
It sucks having to use a shadow buffer, even if DMA does it, it still means additional ~1GB/s of memory bandwidth wasted (~500MB/s for reading + ~500MB/s for writing to TILER), which adds to ~500MB/s needed for DISPC to update the screen and whatever is needed for CPU to draw the frame. I hope ED makes the right decision and at least uses lower resolution screen.
Gražvydas
On 01/04/14 14:41, Grazvydas Ignotas wrote:
Hi,
Nice, thanks for figuring it out.
Btw, please try to add me in "To:" for the post, as I may well miss the reply if it's not directed to me.
On Tue, Apr 1, 2014 at 9:58 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
I was able to get rid of the L3 errors when using TILER 2D buffer. Patch attached. It's illegal to use caching on TILER 2D buffers, so that was causing the issues.
Hmm, that was write combining, not caching. Shame even that doesn't
I was using "caching" in the broad sense. write-combining is a form of caching. So the only allowed option is to disable all caching.
I have to say I'm not 100% sure about the above. It maybe that write-combining works with certain kinds of CPU accesses. But I still guess that disabling the caching is a safe generic fix here.
work, accessing strongly ordered memory will be very slow even if the page fault problem is fixed.
I don't know about "very slow", but yes, it will definitely affect the performance. Do you happen to have any numbers?
Do you have any ideas what kind of access patters to the fb are common? Is it normal to draw pixels here and there? I hope not. If the normal pattern is to copy bigger pieces to the framebuffer, the performance hit may not be huge (just guessing).
It sucks having to use a shadow buffer, even if DMA does it, it still means additional ~1GB/s of memory bandwidth wasted (~500MB/s for reading + ~500MB/s for writing to TILER), which adds to ~500MB/s needed for DISPC to update the screen and whatever is needed for CPU to draw the frame. I hope ED makes the right decision and at least uses lower resolution screen.
Yes, I agree. TILER + very high resolution screen sounds risky to me, if the target is to support "all" applications (as in, compared to, say, all apps working on top of android compositor which uses sgx or such).
Tomi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/01/2014 03:29 PM, Tomi Valkeinen wrote:
On 01/04/14 14:41, Grazvydas Ignotas wrote:
Hi,
Nice, thanks for figuring it out.
Btw, please try to add me in "To:" for the post, as I may well miss the reply if it's not directed to me.
ok..
On Tue, Apr 1, 2014 at 9:58 AM, Tomi Valkeinen
tomi.valkeinen@ti.com wrote:
I was able to get rid of the L3 errors when using TILER 2D buffer. Patch attached. It's illegal to use caching on TILER 2D buffers, so that was causing the issues.
Hmm, that was write combining, not caching. Shame even that doesn't
I was using "caching" in the broad sense. write-combining is a form of caching. So the only allowed option is to disable all caching.
I have to say I'm not 100% sure about the above. It maybe that write-combining works with certain kinds of CPU accesses. But I still guess that disabling the caching is a safe generic fix here.
work, accessing strongly ordered memory will be very slow even if the page fault problem is fixed.
I don't know about "very slow", but yes, it will definitely affect the performance. Do you happen to have any numbers?
I've measured it now by using omap_bo_new(), which creates 1D (nontiled) buffer object and allows to specify OMAP_BO_* cacheability flags. I've hacked it to always use contiguous buffers too and verified that no page faults are happening. Tests are done on 1080*1920 32bpp buffer, first number pair is from constantly redrawing color patterns (memset() basically), second is memcpy() from normal buffer.
OMAP_BO_CACHED: ~550fps (~4GB/s), 192fps (1518 MB/s) (there is corruption on screen and performance is too high as I'm not flushing cache, so some writes are probably hitting cache and not reaching RAM) OMAP_BO_WC: 120fps (940MB/s), 126fps (996MB/s) OMAP_BO_UNCACHED: 8fps (~64MB/s), 16fps (126MB/s) (I'm unsure why memcpy is faster, I think it's because it's using NEON stores)
As you can see as uncached/strongly ordered it's pretty much unusable. I remember the same from my tests on OMAP3. ARM manual states that ARM has to wait for acknowledge of every write of strongly ordered memory, no wonder it's so slow.
Do you have any ideas what kind of access patters to the fb are common? Is it normal to draw pixels here and there? I hope not. If the normal pattern is to copy bigger pieces to the framebuffer, the performance hit may not be huge (just guessing).
It depends on the program.. Something like drawing small 8x8 sprites at random locations is not that uncommon. On pandora we're using huge pages and it helps with TLB misses at least (drawing vertical lines, for example, is several times faster on huge pages).
It sucks having to use a shadow buffer, even if DMA does it, it still means additional ~1GB/s of memory bandwidth wasted (~500MB/s for reading + ~500MB/s for writing to TILER), which adds to ~500MB/s needed for DISPC to update the screen and whatever is needed for CPU to draw the frame. I hope ED makes the right decision and at least uses lower resolution screen.
Yes, I agree. TILER + very high resolution screen sounds risky to me, if the target is to support "all" applications (as in, compared to, say, all apps working on top of android compositor which uses sgx or such).
Tomi
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
It seems my mail client reacted strangely to Tomi's signature, maybe this will look better.
On 04/02/2014 04:04 AM, Grazvydas Ignotas wrote:
On 04/01/2014 03:29 PM, Tomi Valkeinen wrote:
On 01/04/14 14:41, Grazvydas Ignotas wrote:
Hi,
Nice, thanks for figuring it out.
Btw, please try to add me in "To:" for the post, as I may well miss the reply if it's not directed to me.
ok..
On Tue, Apr 1, 2014 at 9:58 AM, Tomi Valkeinen
tomi.valkeinen@ti.com wrote:
I was able to get rid of the L3 errors when using TILER 2D buffer.
Patch
attached. It's illegal to use caching on TILER 2D buffers, so that was causing the issues.
Hmm, that was write combining, not caching. Shame even that doesn't
I was using "caching" in the broad sense. write-combining is a form of caching. So the only allowed option is to disable all caching.
I have to say I'm not 100% sure about the above. It maybe that write-combining works with certain kinds of CPU accesses. But I still guess that disabling the caching is a safe generic fix here.
work, accessing strongly ordered memory will be very slow even if the page fault problem is fixed.
I don't know about "very slow", but yes, it will definitely affect the performance. Do you happen to have any numbers?
I've measured it now by using omap_bo_new(), which creates 1D (nontiled) buffer object and allows to specify OMAP_BO_* cacheability flags. I've hacked it to always use contiguous buffers too and verified that no page faults are happening. Tests are done on 1080*1920 32bpp buffer, first number pair is from constantly redrawing color patterns (memset() basically), second is memcpy() from normal buffer.
OMAP_BO_CACHED: ~550fps (~4GB/s), 192fps (1518 MB/s) (there is corruption on screen and performance is too high as I'm not flushing cache, so some writes are probably hitting cache and not reaching RAM) OMAP_BO_WC: 120fps (940MB/s), 126fps (996MB/s) OMAP_BO_UNCACHED: 8fps (~64MB/s), 16fps (126MB/s) (I'm unsure why memcpy is faster, I think it's because it's using NEON stores)
As you can see as uncached/strongly ordered it's pretty much unusable. I remember the same from my tests on OMAP3. ARM manual states that ARM has to wait for acknowledge of every write of strongly ordered memory, no wonder it's so slow.
Do you have any ideas what kind of access patters to the fb are common? Is it normal to draw pixels here and there? I hope not. If the normal pattern is to copy bigger pieces to the framebuffer, the performance hit may not be huge (just guessing).
It depends on the program.. Something like drawing small 8x8 sprites at random locations is not that uncommon. On pandora we're using huge pages and it helps with TLB misses at least (drawing vertical lines, for example, is several times faster on huge pages).
It sucks having to use a shadow buffer, even if DMA does it, it still means additional ~1GB/s of memory bandwidth wasted (~500MB/s for reading + ~500MB/s for writing to TILER), which adds to ~500MB/s needed for DISPC to update the screen and whatever is needed for CPU to draw the frame. I hope ED makes the right decision and at least uses lower resolution screen.
Yes, I agree. TILER + very high resolution screen sounds risky to me, if the target is to support "all" applications (as in, compared to, say, all apps working on top of android compositor which uses sgx or such).
Tomi
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 02/04/14 04:17, Grazvydas Ignotas wrote:
It seems my mail client reacted strangely to Tomi's signature, maybe this will look better.
Odd... Well, you're sending plaintext+html emails, not only plaintext mails, even though the older emails from you were plain plaintext mails.
On 04/02/2014 04:04 AM, Grazvydas Ignotas wrote:
On 04/01/2014 03:29 PM, Tomi Valkeinen wrote:
I've measured it now by using omap_bo_new(), which creates 1D (nontiled) buffer object and allows to specify OMAP_BO_* cacheability flags. I've hacked it to always use contiguous buffers too and verified that no page faults are happening. Tests are done on 1080*1920 32bpp buffer, first number pair is from constantly redrawing color patterns (memset() basically), second is memcpy() from normal buffer.
OMAP_BO_CACHED: ~550fps (~4GB/s), 192fps (1518 MB/s) (there is corruption on screen and performance is too high as I'm not flushing cache, so some writes are probably hitting cache and not reaching RAM) OMAP_BO_WC: 120fps (940MB/s), 126fps (996MB/s) OMAP_BO_UNCACHED: 8fps (~64MB/s), 16fps (126MB/s) (I'm unsure why memcpy is faster, I think it's because it's using NEON stores)
Yes, I think memcpy may use NEON. I also understood (from a TI internal mail thread) that using NEON to copy to/from TILER may be illegal, as with NEON something related to memory accesses is undefined and may not be compatible with TILER. But, I really didn't quite understand it all, so I may not be right.
As you can see as uncached/strongly ordered it's pretty much unusable. I remember the same from my tests on OMAP3. ARM manual states that ARM has to wait for acknowledge of every write of strongly ordered memory, no wonder it's so slow.
Yes, TILER does really sound unusable with CPU. I'll try to ask internally for verification.
Tomi
Am Tue, 1 Apr 2014 14:41:32 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
wow, thanks a lot for that quick help and the suggestions, Tomi :)
I hope ED makes the right decision and at least uses lower resolution screen.
Well, I ordered 5 samples of that screen, here is my current plan:
1. Let Nikolaus create a few new display PCBs for that display where we can optionally add the Solomon Tech chip 2. Test both displays with TILER for rotation. Check cpu and battery usage as well as overall usefulness (i.e. as mentioned FireFox ignores dpi and is unusable with default settings, I will test multiple standard programs). 3. Test the BOE display incl the Solomon Systech rotation chip and compare the differences of CPU usage.
Right now, I'm in favour of the BOE LCD, for various reasons:
1. Leadtime is 20 days (LG has 12 weeks and didn't even keep them last time) 2. BOE offers all needed datasheets without any issues 3. MOQ of the BOE one is 5 pcs, LG has 5000. 4. Price! The LG display is about 65 - 70 EUR. Applying the touchscreen does cost 10 EUR, I don't know he price of the touchscreen yet, but it will probably be around 2 - 4 EUR. So in total: about 80 - 85 EUR. The BOE screen is 55 EUR when ordering samples - with 1k it will probably be about 35 EUR. The touchscreen can most probably be applied by BOE directly and will cost a few EUR. (I'll get these details within a few days). 5. The LG display can go EOL anytime. The BOE display is currently being used in many chinese smartphone displays, so it'll not go EOL anytime soon.
So our source is more reliable, I can buy 1000 for about 40,000 EUR (instead needing to get 400,000 EUR to be able to buy 5k of the LGs) and we have a better support as well and our system will be faster and probably more useful (as we don't need to fix so many apps to be usable on that high resolution)
So I want to test that, but it seems to me the BOE is the better choice.
Am 01.04.2014 um 15:03 schrieb Michael Mrozek:
Am Tue, 1 Apr 2014 14:41:32 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
wow, thanks a lot for that quick help and the suggestions, Tomi :)
I hope ED makes the right decision and at least uses lower resolution screen.
Well, I ordered 5 samples of that screen, here is my current plan:
- Let Nikolaus create a few new display PCBs for that display where we
can optionally add the Solomon Tech chip
Yes, should not be difficult.
Maybe the easiest solution would be to make a modified variant of the simple EVM adapter first.
I remember the data sheet of the Solomon chip was attached to some recent mail but I don't remember the one of the display.
- Test both displays with TILER for rotation. Check cpu and battery
usage as well as overall usefulness (i.e. as mentioned FireFox ignores dpi and is unusable with default settings, I will test multiple standard programs). 3. Test the BOE display incl the Solomon Systech rotation chip and compare the differences of CPU usage.
Right now, I'm in favour of the BOE LCD, for various reasons:
- Leadtime is 20 days (LG has 12 weeks and didn't even keep them last
time) 2. BOE offers all needed datasheets without any issues 3. MOQ of the BOE one is 5 pcs, LG has 5000. 4. Price! The LG display is about 65 - 70 EUR. Applying the touchscreen does cost 10 EUR, I don't know he price of the touchscreen yet, but it will probably be around 2 - 4 EUR. So in total: about 80 - 85 EUR. The BOE screen is 55 EUR when ordering samples - with 1k it will probably be about 35 EUR. The touchscreen can most probably be applied by BOE directly and will cost a few EUR. (I'll get these details within a few days). 5. The LG display can go EOL anytime.
They likely will have a successor with slightly modified specs. But it is very unlikely that they will not have a Full HD panel. 5 inch is "the standard" for smartphones and LG mobile is trying to follow on the heels of Apple and Samsung.
The BOE display is currently being used in many chinese smartphone displays, so it'll not go EOL anytime soon.
So our source is more reliable, I can buy 1000 for about 40,000 EUR (instead needing to get 400,000 EUR to be able to buy 5k of the LGs) and we have a better support as well and our system will be faster and probably more useful (as we don't need to fix so many apps to be usable on that high resolution)
Yes, the commercial side is much better. Well, there is more competition for this resolution. On the other side the display is one of the key components/ features of the Pyra and a higher resolution would be more outstanding and unique, even if more expensive.
But in the end you must decide the whole package ("ahead-ness", complexity, risk, cost, etc.).
So I want to test that, but it seems to me the BOE is the better choice.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 04/01/2014 04:03 PM, Michael Mrozek wrote:
Am Tue, 1 Apr 2014 14:41:32 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
wow, thanks a lot for that quick help and the suggestions, Tomi :)
I hope ED makes the right decision and at least uses lower resolution screen.
Well, I ordered 5 samples of that screen, here is my current plan:
- Let Nikolaus create a few new display PCBs for that display where we
can optionally add the Solomon Tech chip 2. Test both displays with TILER for rotation. Check cpu and battery usage as well as overall usefulness (i.e. as mentioned FireFox ignores dpi and is unusable with default settings, I will test multiple standard programs).
Assuming you mean still testing LG, I don't know how you want to test it. Tomi's fix gets rid of errors, but brings the performance even more down. As it is now it's not even fast enough to scale 320x240, OMAP5 can't even emulate megadrive with that.
The only options that may work are software rotation or shadow buffer + DMA with 1GB/s loss, but we don't even have code for that and it's unclear how to implement it.
Grazvydas