Hello Andreas, I just wanted to follow up on this issue. I debugged the assertion issue further. There are two reasons for the assertion failure. One, when the buffer underruns for the last update of the frame, endFrameEvent is scheduled without clearing the pixelBufferSize. Therefore endFrame() complains that pixel buffer size is not zero. Second, even if we make pixelBufferSize 0, if dma response comes before the endFrame() is invoked, dmaDone() fills the buffer with the transaction data. And eventually when endFrame() is invoked, assertion fails again. I locally fixed it by 1) clearing pixel buffer size before scheduling endFrameEvent() if the frame was underrun 2) Conditionally filling the pixel buffer in dmaDone() only if the frame was not underrun.
I haven't yet figured out the reason for the underrun. Though low memory frequency looked like the issue in the beginning, further debugging revealed that not all simulations with low frequencies result in underruns. Infact, for a couple of benchmarks buffer under run happens at 300MHz and not at 200MHz of memory frequency. Also, I only observed 1 frame drop rate per simulation, which happens right after switching in most of the cases. However, not every memory frequency switch results in frame drop. We are currently happy with low frame drop rate :-) and are moving past this issue. Thanks for your inputs so far. Thank you, -Rizwana On Fri, Mar 6, 2015 at 3:18 AM, Andreas Hansson <[email protected]> wrote: > Hi Rizwana, > > You are of course free to model any system you want :-). You should be > able to change the resolution in the DTB for some retro VGA action. > > That said, if you’re looking at a mobile system, then the display has to > be fed, and anything less than 1080p is hardly representative of a modern > SoC. We are not talking about a GPU here, this is the LCD controller that > needs to feed the panel, so missing a pixel is disastrous. Also SPEC is > probably not a very representative workload for a mobile system…just saying. > > Andreas > > From: Rizwana Begum <[email protected]> > Date: Thursday, 5 March 2015 20:04 > To: Andreas Hansson <[email protected]> > Cc: gem5 users mailing list <[email protected]> > Subject: Re: [gem5-users] HDLcd buffer underrun with low memory frequency > > Hello Andreas, > > Thank you for your quick response. Sure, I will run gdb through Gem5 for > the second issue. > > For the buffer under run issue, can we not model low resolution (low > buffer size) and low frame rate screen? Indeed, for applications that don't > need high resolution and high frame rate of the screen, the difference > might not be visible at all. I am not making case to change screen > resolution/frame rate based on applications, however, for my simulations to > make sense, I can use lower resolutions. All I am simulating at this point > is SPEC, and I understand that I will have to limit how low I can scale > memory frequency to for interesting system level apps (like bbench). > > Thank you, > -Rizwana > > On Thu, Mar 5, 2015 at 12:10 PM, Andreas Hansson <[email protected]> > wrote: > >> Hi Rizwana, >> >> 1) By throttling the DRAM you are essentially starving the HDLCD and it >> is not able to put pixels on the screen fast enough. On a really system >> this is entirely unacceptable as you’d most likely end up with horrible >> screen distortion. Hence, it must be avoided at all cost. At the moment >> there is no QoS mechanism in the gem5 DRAM controller (since it opens up a >> tremendously large design space). In any real implementation the LCD >> controller would be firm real time, and you must make sure an underrun >> never happens. >> >> 2) That sounds unfortunate. It would be good to run that through gdb >> and figure out what is going wrong. It should either be happy or tell you >> it’s an underrun. >> >> Andreas >> >> >> From: Rizwana Begum via gem5-users <[email protected]> >> Reply-To: Rizwana Begum <[email protected]>, gem5 users mailing list >> <[email protected]> >> Date: Thursday, 5 March 2015 16:40 >> To: gem5 users mailing list <[email protected]> >> Subject: [gem5-users] HDLcd buffer underrun with low memory frequency >> >> Hello All, >> >> I am using Gem5 to simulate system CPU and DRAM frequency scaling. I am >> running ARM full system simulation with detailed CPU type and LPDDR3 dram >> controller with default configurations. I run simulations with android >> jelly bean image. I modified Gem5 and associated DRAM controller with a new >> clock domain. I set frequencies using userspace governors from kernel. So >> far my simulations have been successful with good range of CPU (100MHz to >> 1000MHz) and DRAM frequencies (200MHz to 800MHz). >> >> However, I am running into two issues related to "HDLcd" controller >> with low memory frequencies. >> >> 1) I get following warning when memory frequency is set to 200/300MHz: >> warn: HDLcd controller buffer underrun >> I am guessing that the warning is coming as the Lcd buffer is not >> completely filled due of low memory speeds (?). >> >> 2) With two particular frequency combinations (CPU, DRAM) = (100MHz, >> 300MHz) and (is 400MHz, 300MHz) I get following assertion failure. >> build/ARM/dev/arm/hdlcd.cc:554: void HDLcd::endFrame(): Assertion >> `pixelBufferSize == 0' failed. >> The second issue doesn't occur with DDR3. Could the issue be due to >> lower bandwidth of LPDDR3? >> >> I am hoping that by adjusting either the resolution, pixel buffer size >> or buffer filling rate, I might be able to solve the issues. I am not >> familiar with the LCD controllers, so I am having hard time figuring out >> the solution for the issues. I would appreciate any inputs from people >> familiar with HDLcd, DRAM controllers or overall full system. >> >> Thank you, >> -Rizwana >> >> >> -- IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >> Registered in England & Wales, Company No: 2557590 >> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >> Registered in England & Wales, Company No: 2548782 >> > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
