Re: OpenCL for Panda
On 02/12/2013 05:01 AM, Tom Gall wrote: Thanks nico. Yes that was one of the posts I had run across. Bummer that things aren't more widely released but o well. At this point I was just looking to do a few experiments on omap hardware. Going to the TSC just for experimentation purposes is probably more trouble than it's worth. Tom, Isn't piglit getting OpenCL support? Seems like an obvious expansion of the piglit work in that case ;-) cheers, Jesse Regards, Tom On Tue, Feb 12, 2013 at 4:11 AM, Nicolas Dechesne wrote: Hi, On Tue, Feb 12, 2013 at 6:30 AM, Tom Gall wrote: I was looking for the OpenCL SDK for Omap 4xxx, For the panda es preferred I guess. just the SDK wouldn't be enough, as TI does not release the OpenCL libraries that the SDK rely on. I've seen references that in order to obtain access to it that one needs some sort of agreement in place with TI & Imagination. From a Linaro standpoint do we have this? Do we know who to contact? no, Linaro does not have access to that. I guess you've read that forum post already: https://groups.google.com/d/topic/pandaboard/RO1ONkVcZhw/discussion that is still valid as of today. I am not sure what you're planning to do with OpenCL, but at this point, I think that bringing this to TSC and/or Linaro board looks like the only approach (TI has representative in each group). If TSC approves an OpenCL 'task/activity' on OMAP, then will have to figure out a solution for that. cheers nico "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Tech Lead, Graphics Working Group | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Jesse Barker Principal Software Engineer ARM +1 (408) 576-1423 -- 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. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: running an armel image on 12.04
Scott, The Ubuntu-desktop evaluation builds for 12.04 are based upon Ubuntu Precise, which is officially armhf, so there is no armel support. If you need armel, I think you'll have to use something older, but it would be better to rebuild your binary if that's possible. cheers, Jesse On Tue, May 22, 2012 at 1:08 PM, Scott Douglass wrote: > Hi, > > > > I’m trying to run an old armel image on 12.04 on Snowball. It doesn’t run > because there’s no armel support; starting with a missing /lib/ld-linux.so.3 > > > > How can I add armel support? I tried this: > > > > # dpkg --add-architecture armel > > dpkg: error: unknown option --add-architecture > > > > # apt-get update ; apt-get install dpkg > > [...] > > dpkg is already the newest version. > > > > # dpkg-query --show dpkg > > dpkg 1.16.1.2ubuntu7 > > > > Thanks for any pointers you can give me. > > > -- 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. > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New Gator version ready for Linaro kernels / Mali
On Thu, May 17, 2012 at 3:33 PM, Andy Green wrote: > On 17/05/12 21:26, Somebody in the thread at some point said: >> >> On Thu, May 17, 2012 at 2:21 PM, Scott Bambrough >> wrote: >>> >>> On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote: On Thu, 2012-05-17 at 07:42 +0800, Andy Green wrote: > > > Just curious... how many LTs have Mali stuff? If it's more than one, > we > should perhaps be talking about moving it to > linux-linaro-core-tracking. We have two teams with three different versions of the driver ;-) with, I suspect, custom modifications (different memory management components?). >>> >>> >>> >>> Yes, there are three different memory managers (UMP from ARM, HWMEM from >>> STE, and UMM). >>> From my bystanders point of view, the interaction with closed source binary blobs seems to cause people enough nightmares without also trying to converge code-lines between teams. Especially when engineering resources are spread so thin. Fortunately (?), the two teams have the drivers under different paths with different module and Kconfig option naming, so they could coexist in the same tree. >>> >>> >>> >>> It would be best if the driver and user space was converted to use UMM so >>> we >>> could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as >>> he >>> may have some info that is relevant. >> >> >> Scott is right, and we are pushing slowly in that direction, but it >> will be a while before that is possible for all Mali400 instances >> could be supported from a single stack. > > > What does this mean for the unified kernel effort then? > > We should attempt to unify kernels excluding Mali, or we should wrap or > capture the differences in Mali? > > Is there anything that the unified kernel effort can do (I mean in terms of > slotting things in llct and the like) that can converge with where > UMM-uber-alles is headed? Naive question alert... If the Mali driver is an out-of-tree module, does it matter? cheers, Jesse > > -Andy > > -- > Andy Green | TI Landing Team Leader > Linaro.org │ Open source software for ARM SoCs | Follow Linaro > http://facebook.com/pages/Linaro/155974581091106 - > http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New Gator version ready for Linaro kernels / Mali
On Thu, May 17, 2012 at 2:21 PM, Scott Bambrough wrote: > On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote: >> >> On Thu, 2012-05-17 at 07:42 +0800, Andy Green wrote: >>> >>> Just curious... how many LTs have Mali stuff? If it's more than one, we >>> should perhaps be talking about moving it to linux-linaro-core-tracking. >> >> >> We have two teams with three different versions of the driver ;-) with, >> I suspect, custom modifications (different memory management >> components?). > > > Yes, there are three different memory managers (UMP from ARM, HWMEM from > STE, and UMM). > >> From my bystanders point of view, the interaction with closed source >> binary blobs seems to cause people enough nightmares without also trying >> to converge code-lines between teams. Especially when engineering >> resources are spread so thin. >> >> Fortunately (?), the two teams have the drivers under different paths >> with different module and Kconfig option naming, so they could coexist >> in the same tree. > > > It would be best if the driver and user space was converted to use UMM so we > could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as he > may have some info that is relevant. Scott is right, and we are pushing slowly in that direction, but it will be a while before that is possible for all Mali400 instances could be supported from a single stack. cheers, Jesse > > Scott > > -- > Scott Bambrough > Technical Director, Member Services > Linaro Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Standardized kernel interface for 2D blitters
BTW, I don't think it was explicitly in the phoronix article, but the actual source for omapdrm is at drivers/staging/omapdrm. cheers, Jesse On Tue, May 15, 2012 at 8:03 PM, Jesse Barker wrote: > OK, so with respect to that article, we've been working with our > members to provide KMS drivers for their SoCs. The results are in > varying states of completeness and availability, but I would expect > that to improve in the coming cycles. You should be able to find DRM > drivers for pandaboard (omapdrm: see > http://www.phoronix.com/scan.php?page=news_item&px=MTA5MDg) and origen > (exynos - this driver is already upstream in drivers/gpu/drm/exynos) > with patches out for review on those all the time on the dri-devel > list. Snowball support has not quite made it to igloocommunity, but > that should be in progress. > > It's a work in progress, but we are making that progress all the time. > > I hope this helps. > > cheers, > Jesse > > On Tue, May 15, 2012 at 7:45 PM, Ilyes Gouta wrote: >> Hi Jesse, >> >> Here: http://www.phoronix.com/scan.php?page=news_item&px=OTI0MA and >> http://lists.freedesktop.org/archives/wayland-devel/2011-March/000855.html >> >> It doesn't propose a unified interface for 2D accelerators on SoCs, though. >> >>> There's nothing I'm aware of that would define what you are asking >>> (apart from the Xserver's EXA framework which certainly isn't new or >> >> Yes, but that's heavily geared towards X11. >> >>> in the kernel). Even the interfaces exported by DRM require user >>> space code to orchestrate them (i.e., no kernel acceleration in the >>> purest sense). >> >> It just that it's kind of common that SoCs have separate IPs for >> handling 2D and 3D acceleration, not like PC world. And client code >> could live on both kernel and user lands, hence a need for arbitration >> and so on. >> >> I was just asking, out of curiosity. >> >> -Ilyes >> >> On Tue, May 15, 2012 at 6:11 PM, Jesse Barker >> wrote: >>> Can you point out the article you're referring to that mentioned the >>> Linaro project? >>> >>> There's nothing I'm aware of that would define what you are asking >>> (apart from the Xserver's EXA framework which certainly isn't new or >>> in the kernel). Even the interfaces exported by DRM require user >>> space code to orchestrate them (i.e., no kernel acceleration in the >>> purest sense). >>> >>> cheers, >>> Jesse >>> >>> On Tue, May 15, 2012 at 5:59 PM, Ilyes Gouta wrote: >>>> Hi Christian, >>>> >>>> Yes dma-buf is part of the picture, but rather if any work has been >>>> done to define an interface for the device itself, not the buffers. >>>> >>>> I do know that these are mostly managed from user-space for >>>> performance reasons, however I was curious to see if anything has been >>>> in the works for kernel-space (kind of drm but for much more tailored >>>> for 2D blitters). >>>> >>>> -Ilyes >>>> >>>> On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis >>>> wrote: >>>>> On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: >>>>>> I've previously read (probably on Phoronix) that Linaro is working out >>>>>> a 'standard' kernel interface for 2D blitters IPs as commonly found on >>>>>> SoCs. >>>>>> >>>>>> Has it ever been the case? If yes, are there any >>>>>> documentation/references online? >>>>> >>>>> I wonder if you are talking about dma-buf and the other collection of >>>>> work around Unified Memory Management: >>>>> >>>>> https://wiki.linaro.org/OfficeofCTO/MemoryManagement >>>>> >>>>> It's not really specific for 2D blitter IPs, but it does define how >>>>> memory can be allocated and shared between different devices, >>>>> particularly between the CPU, display controller and GPU IP. >>>>> -- >>>>> Christian Robottom Reis, Engineering VP >>>>> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 >>>>> Linaro.org: Open Source Software for ARM SoCs >>>> >>>> ___ >>>> linaro-dev mailing list >>>> linaro-dev@lists.linaro.org >>>> http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Standardized kernel interface for 2D blitters
OK, so with respect to that article, we've been working with our members to provide KMS drivers for their SoCs. The results are in varying states of completeness and availability, but I would expect that to improve in the coming cycles. You should be able to find DRM drivers for pandaboard (omapdrm: see http://www.phoronix.com/scan.php?page=news_item&px=MTA5MDg) and origen (exynos - this driver is already upstream in drivers/gpu/drm/exynos) with patches out for review on those all the time on the dri-devel list. Snowball support has not quite made it to igloocommunity, but that should be in progress. It's a work in progress, but we are making that progress all the time. I hope this helps. cheers, Jesse On Tue, May 15, 2012 at 7:45 PM, Ilyes Gouta wrote: > Hi Jesse, > > Here: http://www.phoronix.com/scan.php?page=news_item&px=OTI0MA and > http://lists.freedesktop.org/archives/wayland-devel/2011-March/000855.html > > It doesn't propose a unified interface for 2D accelerators on SoCs, though. > >> There's nothing I'm aware of that would define what you are asking >> (apart from the Xserver's EXA framework which certainly isn't new or > > Yes, but that's heavily geared towards X11. > >> in the kernel). Even the interfaces exported by DRM require user >> space code to orchestrate them (i.e., no kernel acceleration in the >> purest sense). > > It just that it's kind of common that SoCs have separate IPs for > handling 2D and 3D acceleration, not like PC world. And client code > could live on both kernel and user lands, hence a need for arbitration > and so on. > > I was just asking, out of curiosity. > > -Ilyes > > On Tue, May 15, 2012 at 6:11 PM, Jesse Barker wrote: >> Can you point out the article you're referring to that mentioned the >> Linaro project? >> >> There's nothing I'm aware of that would define what you are asking >> (apart from the Xserver's EXA framework which certainly isn't new or >> in the kernel). Even the interfaces exported by DRM require user >> space code to orchestrate them (i.e., no kernel acceleration in the >> purest sense). >> >> cheers, >> Jesse >> >> On Tue, May 15, 2012 at 5:59 PM, Ilyes Gouta wrote: >>> Hi Christian, >>> >>> Yes dma-buf is part of the picture, but rather if any work has been >>> done to define an interface for the device itself, not the buffers. >>> >>> I do know that these are mostly managed from user-space for >>> performance reasons, however I was curious to see if anything has been >>> in the works for kernel-space (kind of drm but for much more tailored >>> for 2D blitters). >>> >>> -Ilyes >>> >>> On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis >>> wrote: >>>> On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: >>>>> I've previously read (probably on Phoronix) that Linaro is working out >>>>> a 'standard' kernel interface for 2D blitters IPs as commonly found on >>>>> SoCs. >>>>> >>>>> Has it ever been the case? If yes, are there any >>>>> documentation/references online? >>>> >>>> I wonder if you are talking about dma-buf and the other collection of >>>> work around Unified Memory Management: >>>> >>>> https://wiki.linaro.org/OfficeofCTO/MemoryManagement >>>> >>>> It's not really specific for 2D blitter IPs, but it does define how >>>> memory can be allocated and shared between different devices, >>>> particularly between the CPU, display controller and GPU IP. >>>> -- >>>> Christian Robottom Reis, Engineering VP >>>> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 >>>> Linaro.org: Open Source Software for ARM SoCs >>> >>> ___ >>> linaro-dev mailing list >>> linaro-dev@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Standardized kernel interface for 2D blitters
Can you point out the article you're referring to that mentioned the Linaro project? There's nothing I'm aware of that would define what you are asking (apart from the Xserver's EXA framework which certainly isn't new or in the kernel). Even the interfaces exported by DRM require user space code to orchestrate them (i.e., no kernel acceleration in the purest sense). cheers, Jesse On Tue, May 15, 2012 at 5:59 PM, Ilyes Gouta wrote: > Hi Christian, > > Yes dma-buf is part of the picture, but rather if any work has been > done to define an interface for the device itself, not the buffers. > > I do know that these are mostly managed from user-space for > performance reasons, however I was curious to see if anything has been > in the works for kernel-space (kind of drm but for much more tailored > for 2D blitters). > > -Ilyes > > On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis > wrote: >> On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: >>> I've previously read (probably on Phoronix) that Linaro is working out >>> a 'standard' kernel interface for 2D blitters IPs as commonly found on >>> SoCs. >>> >>> Has it ever been the case? If yes, are there any >>> documentation/references online? >> >> I wonder if you are talking about dma-buf and the other collection of >> work around Unified Memory Management: >> >> https://wiki.linaro.org/OfficeofCTO/MemoryManagement >> >> It's not really specific for 2D blitter IPs, but it does define how >> memory can be allocated and shared between different devices, >> particularly between the CPU, display controller and GPU IP. >> -- >> Christian Robottom Reis, Engineering VP >> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 >> Linaro.org: Open Source Software for ARM SoCs > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
Funny, I took champion to be the equivalent of the sponsor of a requirement (i.e. to champion the topic at the TSC level). I guess we'd better be more explicit in our nomenclature. cheers, jesse On Tue, Apr 24, 2012 at 11:16 PM, David Rusling wrote: > See my earlier email. They can be different or the same it's up to you... > > Dave > > Sent from my iPad > > On 25 Apr 2012, at 05:50, Arwen Donaghey wrote: > > All, > > My understanding was the session lead is not necessarily the champion. The > champion is the 'guru' or 'owner' of the topic, and the session lead is > exactly that… the session lead. There are a number of sessions covering > various areas of one topic potentially? Please do correct me if this is > wrong. > > Regards, > -- > Arwen Donaghey > Events Manager > > T: +44 1223 TBC | M: +44 7791 279 521 > Suite 220 | The Quorum | Barnwell Road | Cambridge | CB2 8FH > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog > Registered Number: 07180318 | VAT Number: 990 0273 24 > > On 25 Apr 2012, at 03:11, Ricardo Salveti wrote: > > On Tue, Apr 24, 2012 at 7:17 PM, Deepak Saxena wrote: > > On 24 April 2012 03:22, David Rusling wrote: > > All, > > I've created and shared the Connection Sessions spreadsheet, you can find it > > here > > - https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnK-Uyci_D20dFlUX1ZOVm5LWDVudkxJM1B0aS1FWWc#gid=0. > > Arwen is happy that that spreadsheet will be used for the session > > planning. I've added some topics and champions, please contact me to > > arrange more / discuss how best to organise things moving forward. If you > > want a hint, see what Amit's done... > > > What are the responsibilities of the champion vs those of the session lead? > > > Nothing, we're just creating some extra naming for the same things :-) > Tiger, champion, all funny. > > Cheers, > -- > Ricardo Salveti de Araujo > > > > ___ > linaro-android mailing list > linaro-andr...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-android > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Graphics working group components for 2012.03 (cont.)
Hi all, Somehow, I completely forgot about the release for the unity-gles project. All OpenGL|ES enablement for the Ubuntu Unity plugin (the Unity3D "shell") and the nux library has been merged into the respective trunks on launchpad for those projects (lp:unity, lp:nux), so Linaro will not be releasing those. There are 2012.03 release tarballs for compiz itself (both compiz-core and compiz-plugins-main) at https://launchpad.net/unity-gles. These will support Precise only, due to external library dependencies. cheers, Jesse ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Graphics working group components for 2012.03
Hi all, The graphics working group is pleased to announce the 2012.03 release for the following components: - glmark2 * Offscreen rendering support using framebuffer objects. * New command line switch to allow selection of end-of-frame method, - glcompbench * New 'blur' test. * Updated glproxy support. - glproxy * Enhanced selection of EGL vs. GLX based upon new detection API. These are all available for download from their respective project pages, conveniently linked from the project group page at: https://launchpad.net/linaro-graphics-wg The release for the linaro-mm-sig project is being rolled up into the linux-linaro kernel tree (linux-linaro branch of git://git.linaro.org/kernel/linux-linaro-tracking.git) for this cycle, and should see updates between cycles, as well moving forward. Enjoy! cheers, Jesse ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: is there fence like abstraction for hwmem+cma
Hi there, It turns out that a fence object will be one of the next things added to the dma-buf framework. You can check here for an in-progress status page: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/UMM/Status And, the best thing for you to do is join the linaro-mm-sig list for these and other discussions. cheers, jesse On Mon, Feb 27, 2012 at 3:52 PM, Westermann Fu wrote: > Hi, guys: > > As I know linaro is working on a unified memory manager for soc world like a > similar one already exists in PC world (gem/ttm). > But I'm curious about how this manager handle the different sync notify > between various different IP vendor? > As we know, on PC the vsp+capture+graphic+display always done by one > unit--the GPU, if a piece of hardware memory buffer wanted to be zero-copied > between vsp/graphic/display there must be some sync/notify mechanism > otherwise the race condition will occur. On gpu always an interrupt driven > object fence can handle it. But in soc, there is no integrated > vsp/graphic/display, they all may come from various independent ip vendor, > so there may no unified interrupt source can be collected by memory manager > to know whether one buffer hasn't be completed by the previous engine and > the next engine should block wait but without cpu blocked too. Thanks > > Regards > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: nano-summits over google+ hangouts
On Tue, Feb 14, 2012 at 4:35 AM, Stephen Doel wrote: > Hi Tom et al, > > We worked out the problem with remote people dialling in to Linaro Connect. > Basically a nasty feature/bug in Google Hangouts. The detail is: > * If you set up a Hangout from a Linaro G+ account, by default it will look > something like: > https://talkgadget.google.com/hangouts/extras/linaro.org/linaro-blueroom > * Its essential you replace /Linaro.org/ with /talk.google.com/. Then > people outside the Linaro domain will go to the same session as you > The nasty thing is, even with this domain change, when you (as a Linaro > person) go to that hangout, it will provide a link under the Hangout Name of > https://talkgadget.google.com/hangouts/extras/linaro.org/linaro-blueroom, > but still connect you correctly to > https://talkgadget.google.com/hangouts/extras/talk.google.com/linaro-blueroo > m. External people get the correct link all the way through > > Then, as a reminder, external participants can only join with a gmail > account (and the Google empire grows...) This would sound like a deal breaker for general external participation. In spite of some appearances, not all email accounts are hosted by google. cheers, Jesse > > After that, it is absolutely possible. Further, Google will be deploying > Hangouts on Air which will provide a YouTube feed to > 10 participants at > some point. > > When you set the meeting up, you're best off either attaching the hangout > link to a meeting invite, or a separate page as they are pretty hard to > locate within G+ itself > > I suggest when you're ready to schedule your first nano-summit, you contact > me and I'll help you set it all up. > > Thx > > Stephen > > Message: 1 > Date: Mon, 13 Feb 2012 10:07:17 -0600 > From: Tom Gall > To: Linaro Dev > Subject: nano-summits over google+ hangouts > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Hi All, > > >From what I've heard and saw it seemed like the google+ hangouts in > the rooms worked fairly well. (For the very small sample size of the > people I've talked to) > > I'm wondering/tempted to try out as an experiment on going single > topic Multimedia sessions from time to time between Linaro Connects. > Given that a focused single topic session would draw a smaller "crowd" > the 9 person limitation I don't see as a big deal especially with > carefully chosen topics. > > Is this something that is even possible? I know the google+ hangout > over the air is by "invite" only so it's important to know if their > use might be available for more than just linaro connect. > > Thanks! > > -- > Regards, > Tom > > "Where's the kaboom!? There was supposed to be an earth-shattering > kaboom!" Marvin Martian > Multimedia Tech Lead | Linaro.org ? Open source software for ARM SoCs > w) tom.gall att linaro.org > w) tom_gall att vnet.ibm.com > h) tom_gall att mac.com > > > > -- > > Message: 2 > Date: Mon, 13 Feb 2012 11:15:10 -0600 > From: Kurt Taylor > To: Tom Gall > Cc: Linaro Dev > Subject: Re: nano-summits over google+ hangouts > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > On 13 February 2012 10:07, Tom Gall wrote: > >> Hi All, >> >> From what I've heard and saw it seemed like the google+ hangouts in >> the rooms worked fairly well. (For the very small sample size of the >> people I've talked to) >> > > This was the 3rd remote LC for me and BY FAR the most useful and > productive. The hangouts were a tremendous success. My only thought would > be to maybe have a "hallway" hangout for impromptu discussions without > having to think about it. > > >> >> I'm wondering/tempted to try out as an experiment on going single >> topic Multimedia sessions from time to time between Linaro Connects. >> Given that a focused single topic session would draw a smaller "crowd" >> the 9 person limitation I don't see as a big deal especially with >> carefully chosen topics. >> > > I think this would be useful, mainly for the improved quality over some of > the other methods. I'll have to experiment with whiteboarding and screen > sharing, but I think it would work. I'd be willing to put together a > multimedia themed micro-summit to give it a try, maybe sometime between the > mayor conferences. > > >> >> Is this something that is even possible? I know the google+ hangout >> over the air is by "invite" only so it's important to know if their >> use might be available for more than just linaro connect. >> >> Thanks! >> >> -- >> Regards, >> Tom >> >> "Where's the kaboom!? There was supposed to be an earth-shattering >> kaboom!" Marvin Martian >> Multimedia Tech Lead | Linaro.org ? Open source software for ARM SoCs >> w) tom.gall att linaro.org >> w) tom_gall att vnet.ibm.com >> h) tom_gall att mac.com >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> > > > > -- > > Kurt Taylor
Re: Proposal : New Linaro Desktop Wallpaper
Works for me. Nice job, Tom! cheers, Jesse On Thu, Dec 1, 2011 at 2:56 PM, Tom Gall wrote: > Hi All, > > one of the blueprints we have for 11.12 is to modify the LEB/ALIP > images so they include more linaro branding. A linaro wallpaper, maybe > a linaro image as the system is booting, that kind of thing. > > Towards that end (and given that time is short if this is to make > 11.12) I'd like to propose the following graphic be our new wallpaper > image. This would be the image displayed in the background on a > graphical desktop by default. > > I created it in gimp. > > http://people.linaro.org/~tgall/LinaroDesktop-1920x1080-1.png > > Thoughts? Concerns? Feedback? > > -- > Regards, > Tom > > "Where's the kaboom!? There was supposed to be an earth-shattering > kaboom!" Marvin Martian > Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs > w) tom.gall att linaro.org > w) tom_gall att vnet.ibm.com > h) tom_gall att mac.com > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Weekly status Graphics WG - wk39.2011 (20110926-20110930)
On Thu, Oct 6, 2011 at 7:29 AM, Christian Robottom Reis wrote: > On Wed, Oct 05, 2011 at 09:19:18AM -0700, Jesse Barker wrote: >> Those are only the session blueprints for the scheduler. > > Of course, I had forgotten about this silliness. Hopefully this is being > less expensive now that we have less sessions and the UI is a little bit > better. Absolutely. We only have 4 sessions and could possibly have gotten away with slightly fewer. > > Long-term, I really want to see us have the ability to conveniently > schedule a session independently or not of having a blueprint for us. Sure. This is strictly a function of leveraging the summit scheduler. For Cambourne and presumably for SF in February, we won't have to worry about this. cheers, Jesse ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Weekly status Graphics WG - wk39.2011 (20110926-20110930)
Those are only the session blueprints for the scheduler. Once we've captured all the info we need (broken each up into individual feature blueprints that would satisfy the requirements), those will go away (be marked "implemented"). I don't see how we get around it (well, I suppose we could keep our planning manual and ad hoc, but I wanted to make sure folks could use the scheduler to make sure they were able to attend other important sessions). cheers, Jesse On Wed, Oct 5, 2011 at 9:14 AM, Christian Robottom Reis wrote: > On Tue, Oct 04, 2011 at 12:17:11PM +0300, Ilias Biris wrote: >> * Benchmarking: >> https://linaro-public.papyrs.com/public/4143/GWG2011-BENCHMARK-DASHBOARD, >> also >> in Launchpad >> https://blueprints.launchpad.net/linaro-graphics-misc/+spec/linaro-gfxmm-benchmark-dashboard >> >> * Webkit port using CAIRO-GLES: >> https://linaro-public.papyrs.com/public/4146/GWG2011-WEBKIT-CAIRO-GLES/# >> also in Launchpad >> https://blueprints.launchpad.net/linaro-graphics-misc/+spec/linaro-gfxmm-webkit-cairo-gles > > Once we have the show on the road (i.e. the roadmap items estimatded, > approved and scheduled for Q4) would it make sense to kill the > blueprints above? I don't like the idea of having duplication (or a > 1-to-1 mapping) there, and ISTM that you really want to have blueprints > that are smaller sized than what these are. > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: wiki feedback on new front page
+1 on what Fathi said. I wonder if we can't provide a more direct link to the whole topic of "Getting Involved". While some people want to enable their hardware or their own development, but I couldn't find a trail of fewer than 3 links to something like "Send mail to linaro-dev@lists.linaro.org and introduce yourself, we'd love to help you participate". cheers, Jesse On Wed, Sep 28, 2011 at 1:48 PM, Fathi Boudra wrote: > Hi, > > On 28 September 2011 22:59, Andy Doan wrote: >> Michael and I were tasked with making the front page of the Linaro wiki >> a little more developer focused and offloading some of the other >> information to the main website, linaro.org. >> >> We've put together a prototype page and would like to get some feedback >> before making the real switch: >> >> https://wiki.linaro.org/AndyDoan/Sandbox/FrontPage > > "Downloads and Cycles" should be simplified and splitted: > - "Downloads" information should be offloaded to the main website and > link to http://www.linaro.org/downloads/ > - "Cycles" should keep the introduction text and link to /Cycles subsection > - the 3 tables should be moved under /Cycles > - Use a single column instead of two. > - Add a table of contents? > > Cheers, > > Fathi > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Bootchart results
Is this "time to boot to a prompt"? cheers, Jesse On Mon, Sep 12, 2011 at 1:13 PM, Paul Larson wrote: > This time with the attachment :) > > On Mon, Sep 12, 2011 at 2:16 PM, Paul Larson wrote: >> >> I started working on a results view in LAVA for the bootchart results >> since they are now part of the daily runs. This is using a partial copy of >> the data I have locally, so please don't concern yourself too much with the >> actual data in it. A couple of things to point out: >> 1. legend is not placed well, that's something I'm not yet sure how to fix >> as my javascript-fu is lacking here (zyga, any ideas on this?) >> 2. The set of results here is not very large. That's adjustable and when >> it's using live data, should have a lot more data points to better see >> trends >> 3. This is purposefully restricted to a single board. We are not running >> benchmarks in a controlled enough manner as to make comparison of boards to >> one another reasonable, nor is it encouraged due to the collaborative nature >> of Linaro. >> In particular I'm looking for opinions on how it would be most useful to >> display this data. This view shows all 4 image types on a single chart. I >> did a previous version that had them separate. Is there a preference? It >> would also be easy to do both on the same page, but perhaps a bit redundant. >> Thanks, >> Paul Larson > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Graphics WG status report - wk33.2011 (20110815-20110819)
On Tue, Aug 23, 2011 at 3:23 PM, Christian Robottom Reis wrote: > On Wed, Aug 24, 2011 at 01:07:07AM +0300, Ilias Biris wrote: >> How can we get consistent vendor support to get 3d acceleration working >> for the Linaro officially supported platforms? If we are targeting last >> version Ubuntu-based evaluation builds and some of the code we work on >> (and goes upstream) is going through a transition (like unity/nux have >> moved on to oneiric now) then we may be unable to provide meaningful >> releases for the components in question. The real issue we have in GWG >> is 3d acceleration driver support for the next version of ubuntu - we >> don't have any at the moment (AFAIK) for oneiric > > AIUI this is something which all vendors struggle with, but at least for > the OMAP4 we should be in reasonably good shape as TI are committed to > providing the necessary binaries for Oneiric. I raised this with Ricardo > and he was confident it would be okay, so I'm surprised to still see > this in the report. The point is that we _really_ need to have all of our member hardware fully enabled. For all of our evaluation builds. This is a huge pain point for the graphics working group. That's why it is in the report. Not everyone involved with Unity/Nux/Compiz has a working pandaboard. Not everyone working on other projects has a working pandaboard. For some projects (e.g., cairo-gles), OMAP4 doesn't support all of the functionality involved, so even a working pandaboard is of limited use. > > I also don't quite understand why the updated Unity/Nux packages > wouldn't Just Work if installed on Natty -- is the issue that they > require updated X11 and Mesa? I believe that some of the plugin-related interfaces are different and mixing and matching isn't possible (Travis?). cheers, Jesse > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Call for desktop/graphics/mobile tracks for Linux Plumbers' Conf 2011
We have both desktop (for general graphics/media stuff) and mobile tracks at this year's LPC. So if you're working on a topic related to one of the above areas, especially one that has open issues or spans multiple parts of the stack, please submit a topic for discussion at http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals/new against the appropriate track. If you've already submitted a talk to one of these tracks, you will likely be hearing from us over the next week. We're passed earlybird registration, but you can still sign up and attend. Thanks, Jesse Barker, desktop track lead Daniel Stone, mobile track lead ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Community Mumble
Joey, I think this is great! We have a combination need for this: 1) Upstream project interaction where phone-type interaction is desirable. 2) The working group meeting where representatives from member companies who are not Linaro assignees want to participate (for replacing the old conference line). I can send you a short list of launchpad IDs for these two categories. cheers, Jesse On Wed, Jun 22, 2011 at 8:29 AM, Joey Stanford wrote: > Hi Gang, > > In the past few days I've received a few requests to allow community > members access to our Mumble server. > > I don't feel comfortable adding in the large and open linaro-community > team so I am considering making a linaro-community-mumble team to > allow for access. Right now you have to be in ~linaro to have access > to Mumble. > > 1) I'd like to hear your comments on this, especially if you have > alternative suggestions. > > 2) If there are community members who should have mumble access, can > you please send me their Launchpad IDs so I can start assembling a > list. > > Thanks, > > Joey > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.06 milestone, when is it?
https://launchpad.net/linaro/+milestones says 11.06 is June 30, which is what graphics has been using as out target (actually, what we're using for the whole cycle of targets as we thought the goal for this cycle was a more coherent sense of release targets for all of Linaro). cheers, Jesse On Wed, Jun 8, 2011 at 6:43 AM, James Westby wrote: > Hi, > > Currently > > https://launchpad.net/lava/+milestone/11.06 > > says that 11.06 is June 16 while > > https://launchpad.net/linaro-android/+milestone/11.06 > > says June 30 and > > https://launchpad.net/linux-linaro/+milestone/11.06 > > doesn't say when it is. > > We need one date per-milestone or we will get very confused. > > This is currently exhibiting itself as status.linaro.org picking one of > these dates so confusing people who think it is the other one. > > It's not a tools problem though, humans will get just as confused if > they are using the same name for different dates. > > What date is the monthly milestone? > > Thanks, > > James > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Memory Management Mini-Summit Report
t API and its ability to live cleanly with the IOMMU code and to resist breakage from other architecture implementations. At this point, we reviewed what we had done and finalized the outcomes (see the outcomes section at the top). And, with a half an hour to spare, I re-instigated the file descriptors versus unique identifiers discussion from day 2. I think file descriptors were winning by the end (especially after people started posting pointers to code samples of how to actually pass them between processes) Attendees: -- I will likely miss people here trying to list out everyone, especially given that some of the sessions were quite literally overflowing the room we were in. For as accurate an account of attendance as I can muster, check out the list of attendees on the mini-summit wiki page or the discussion blueprints we used for scheduling: https://wiki.linaro.org/Events/2011-05-MM#Attendees https://blueprints.launchpad.net/linaro-graphics-wg/+spec/linaro-graphics-memory-management-summit-1 https://blueprints.launchpad.net/linaro-graphics-wg/+spec/linaro-graphics-memory-management-summit-2 https://blueprints.launchpad.net/linaro-graphics-wg/+spec/linaro-graphics-memory-management-summit-3 The occupants of the fishbowl (the front/center of the room in closest proximity to the microphones) were primarily: Arnd Bergmann Laurent Pinchart Hans Verkuil Mauro Chehab Daniel Vetter Sakari Ailus Thomas Hellstrom Marek Szyprowski Jesse Barker The IRC fishbowl seemed to consist of: Rob Morell Jordan Crouse David Brown There were certainly others both local and remote participating to varying degrees that I do not intend to omit, and a special thanks goes out to Joey Stanford for arranging a larger room for us on days 2 and 3 when we had people sitting on the floor and spilling into the hallway during day 1. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [lsb-discuss] Does anyone care about LSB on arm?
At the risk of overstating the obvious, there are also ABI guarantees at stake here, which in my mind are architecture agnostic. OpenGL applications need to know which bits (API functions) of which core versions can be expected to be resolved during load time and which must be queried through GetProcAddress. LSB specifies this and makes it unambiguous. cheers, Jesse On Wed, Jun 1, 2011 at 8:00 AM, Jeff Licquia wrote: > On 06/01/2011 07:25 AM, Luke Kenneth Casson Leighton wrote: >> >> so in _that_ regard, the question becomes: "are the efforts of the >> free software community better off being spent elsewhere"? and "what >> benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for >> ARM"? forget the proprietary junkies, they'll suck anything from us >> that moves and not give a dime in return. > > That seems to be my cue to provide the community case for the LSB. > > The LSB provides several things to the community: > > - a framework for allowing Linux distributions to pool their userbase and > work together as one platform instead of multiple platforms, one per distro > > - test suites which identifies both compatibility problems and outright > bugs to be detected and fixed > > - a method for targeting builds at multiple distributions at once, both > proprietary and free > > - reporting tools for finding portability problems in built apps, again for > both proprietary and free apps > > We currently provide all of this for 7 architectures. ARM benefits > indirectly (for example, many of the compatibility breaks detected on, say, > x86_64 will affect all archs equally), but indirect support doesn't include > the tools we've developed, and often compatibility issues are arch-specific. > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Moinmoin ratings plugin
This makes a lot of sense with respect to the discussion we had at the graphics working group meeting this morning around component releases; more to the point, exactly how each component gets tested, packaged (and/or tar'd) and pushed out to some publicly visible repository. The idea of letting someone post their own "howto" on the wiki, and then, based upon votes, pushing it to the "official" engineering resources howto section has merit for me. Of course, how the plugin handles votes across revisions would make a difference here, but the idea, in and of itself, seems cool for certain applications of the wiki. cheers, Jesse On Wed, Jun 1, 2011 at 3:44 AM, Ilias Biris wrote: > Folks > > I recently came up with a list of ideas proposed for the problem of the > development cycle. I put those in the wiki, however it soon dawned on me > that others would need to actually edit the wiki in order to give > feedback. Each user could add some comment or +1 or something like that. > Altogether deciphering the results could mean some work going through > the user comments. > > So I want to have a quick and easy way for ratings on the ideas. > Moinmoin supports star ratings, like described here: > http://moinmo.in/RatingSystemForMoin. Basically it allows readers to > rate options given in the wiki page, without having to edit the page, > just click on the stars. > > I made an IT request to have this plugin installed but was asked to > start a discussion in the list, as the usefulness of this plugin is doubted. > > Am I the only one needing some quick way for readers to rate ideas put > on the wiki? If you also have the same need, +1 it by responding to this > thread :-) Hopefully we can have this support added. > > Thank you > > > -- > Ilias Biris, > Aallonkohina 2D 19, 02320 Espoo, Finland > Tel: +358 50 4839608 (mobile) > Email: ilias dot biris at linaro dot org > Skype: ilias_biris > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 1105 delivery of pm, multimedia, graphics
Hi Barry, Most of the components that the graphics WG has released to now (glcompbench, glmark2) are available on their Launchpad project pages and in binary form if debian packaging is useful to you (some in universe and some from the graphics WG PPA. We will be consolidating this in the near future to make it easier to get at this from a single location, as well as growing the number of projects we release. cheers, Jesse On Thu, May 19, 2011 at 2:32 PM, Barry Song <21cn...@gmail.com> wrote: > Hi all, > it is easy to get toolchain/uboot/kernel/android source codes. but i > have been really searching all over the website but still fail to get > source codes of pm(expect powerdebug last updated 6 weeks ago), > multimedia, graphics. so i am really difficult to find delivery of pm, > multimedia, graphics team. is there a delivery list for these teams? > > Thanks very much > Barry > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro development cycle thoughts
To add to Alexandros' thoughts, we typically have our public plan reviews a couple of weeks after LDS, which means that for the most part, all engineering blueprints for the coming cycle must be done by then (before then for the benefit of those compiling the slides, etc. for the plan reviews ;-). So, the idea that work on the closing cycle can still be ongoing even by the week before LDS is almost an illusion. Some of this might point to the idea that if we've done our jobs planning and scoping appropriately, no remaining work items will be deep or complex so that the LDS pre-preplanning and the output processing that goes on afterward (yet before the official end of cycle) will interrupt us. Of course, it's not a perfect world, so we may not get the smoothest of transitions, but we should at least be able to improve the transition with each passing cycle. cheers, Jesse On Tue, May 17, 2011 at 9:54 AM, Alexandros Frantzis wrote: > Hi all, > > I completely missed the Linaro release process session during LDS, but > here are my thoughts on the Linaro development cycle. > > Currently, the Linaro cycle lags behind the Ubuntu cycle by one month. > This is done so that the Linaro releases are based on a stable system. > > Unfortunately, this scheme causes some disruption for me (and I suspect for > other engineers, too). The problem is that while the current Linaro cycle is > still ongoing, we need to start planning for next-cycle/LDS, attend LDS and > after that investigate some more and create the specifications. This is hard > and time consuming work and I am sure not many people (including me) can > continue to work effectively on their remaining work items while drafting > specifications or attending LDS. The problem is exacerbated further because > the > end of cycle is usually a very strenuous period for engineers. > > So my questions/suggestions are: > > 1. Do other engineers feel this way? > > 2. From people's experience, has the one-month-after-ubuntu schedule provided > concrete advantages? Could we get away with less (e.g. one week)? > > 3. If we don't change anything we should at least make this situation very > clear > to engineers/managers, so that they can plan accordingly: > ~5 months of normal work, starting two weeks after LDS and ending one week > before the next LDS. Keep the rest for planning/LDS and spec-ing, plus some > light work. > > Thoughts? > > Thanks, > Alexandros > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Embedded memory management interest group list
Hi all, One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics I am working on getting the key technical decision makers to provide input and participate in the requirements collection and design for a unified solution. We had an initial birds-of-a-feather discussion at the Embedded Linux Conference in San Francisco this past week to kick off the effort in preparation for the first embedded-memory-management mini-sprint in Budapest week of May 9th at Linaro@UDS. One of the outcomes of the BoF was the need for a mailing list to coordinate ideas, planning, etc. The subscription management for the list is located at http://lists.linaro.org/mailman/listinfo/linaro-mm-sig. The mini-summit in Budapest will have live audio and an IRC channel for those that want to participate (details to go out on the list). We expect to have additional summits over the course of the cycle, with the next one likely at Linux Plumbers in September (though, I would like to try for one more before then). cheers, Jesse ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Embedded memory management interest group list
Hi all, One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics I am working on getting the key technical decision makers to provide input and participate in the requirements collection and design for a unified solution. We had an initial birds-of-a-feather discussion at the Embedded Linux Conference in San Francisco this past week to kick off the effort in preparation for the first embedded-memory-management mini-sprint in Budapest week of May 9th at Linaro@UDS. One of the outcomes of the BoF was the need for a mailing list to coordinate ideas, planning, etc. The subscription management for the list is located at http://lists.linaro.org/mailman/listinfo/linaro-mm-sig. The mini-summit in Budapest will have live audio and an IRC channel for those that want to participate (details to go out on the list). We expect to have additional summits over the course of the cycle, with the next one likely at Linux Plumbers in September (though, I would like to try for one more before then). cheers, Jesse ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: git merge question
All these git related puns are killing me :-) On Fri, Apr 8, 2011 at 8:46 AM, Will Deacon wrote: > > On Fri, Apr 8, 2011 at 3:45 PM, Tixy wrote: > > > On Fri, 2011-04-08 at 10:16 +0100, Dave Martin wrote: > > >> one reason why my understanding of the actual problem here was a bit > > >> patchy. > > > > > > :-) > > > > _not_ intentional! (if you believe me) > > I don't believe you; I think you should consider branching out > into comedy... > > Will > > > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
I'll be at ELC, as well as living in SF, so I'll be around before and after as well. cheers, Jesse On Fri, Mar 25, 2011 at 2:41 PM, Clark, Rob wrote: > On Wed, Mar 16, 2011 at 3:14 AM, Kyungmin Park > wrote: > > > > Rough schedules. > > > > 1. Warsaw meetings (3/16~3/18): mostly v4l2 person and some SoC vendors > > Make a consensence at media developers. and share the information. > > Please note that it's v4l2 brainstorming meeting. so memory > > management is not the main issue. > > 2. ELC (4/11~4/13): DRM, DRI and v4l2 person. > > Fyi, I should be at ELC, at least for a day or two.. it would be nice, > as Andy suggested on other thread, to carve out a timeslot to discuss > in advance, because I'm not sure that I'll be able to be there the > entire time.. > > BR, > -R > > > Discuss GEM/TTM is acceptable for non-X86 system and find out the > > which modules are acceptable. > > We studied the GEM for our environment. but it's too huge and not > > much benefit for us since current frameworks are enough. > > The missing is that no generic memory passing mechanism. We need the > > generic memory passing interface. that's all. > > 3. Linaro (5/9~5/13): ARM, SoC vendors and v4l2 persons. > > I hope several person are anticipated and made a small step for final > goal. > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: regarding memebership to linaro
Thanks for your interest. If you absolutely cannot wait to get involved, or at least to start checking out the work, I suppose you could clone Alexandros' tree at: http://git.linaro.org/gitweb?p=people/afrantzis/cairo.git;a=shortlog;h=refs/heads/gles2 This work is currently under review by the upstream maintainer, and should go in there soon, so you could also look for that commit; when it happens, it will surely be announced on this list. Alexandros, anything else to add? cheers, Jesse On Fri, Mar 25, 2011 at 2:59 AM, ravi nanjundappa < ravi.nanjunda...@gmail.com> wrote: > hi, > > I Would like to participate in the OpenGLES2.0 support to Cairo. > Could you please let me know the procedure to get involved in the GLES > backend support for Cairo ? > > -- > Thanks and Best Regards, > N Ravi > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Some GL benchmarks for ARM devices
Hi all, Thought this might be of interest to folks. http://www.glbenchmark.com/result.jsp?benchmark=glpro20&orderby=405&screen-group=true&screen-group-value=1&submi=OK&screen=4&screen=3&screen=2&screen=1&screen=0&os=0&os=1&os=2&os=3&os=4&version=all&certified_only=1&brand=all http://www.glbenchmark.com/compare.jsp?benchmark=glpro20&showhide=true&certified_only=1&D1=Hardkernel%20ODROID-A&D2=Apple%20iPad%202 The first is an overall comparison (pretty high level) of available boards, and the second is a breakdown of the top 2 results: the Apple iPad2 and the Hardkernel ODROID-A (FWIW, according to androidtablets.net, the odroid-a is an Orion). While this can certainly be a red herring, it might be nice to see these comparisons with identical screen resolutions (i.e. not all performance measurements are sensitive to pixel resolution). cheers, Jesse ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
gt; We need to resolve 2. and 3. > > > > GEM/TTM is mentioned in this thread and there is an overlap of what is > > happening within DRM/DRI/GEM/TTM/KMS and V4L2. The whole idea behind > > DRM is to have one device driver for everything (well at least 2D/3D, > > video codecs, display output/composition), while on a SoC all this is > > on several drivers/IP's. A V4L2 device cannot resolve a GEM handle. > > GEM only lives inside one DRM device (AFAIK). GEM is also mainly for > > "dedicated memory-less" graphics cards while TTM mainly targets > > advanced Graphics Card with dedicated memory. From a SoC point of view > > DRM looks very "fluffy" and not quite slimmed for an embedded device, > > and you cannot get GEM/TTM without bringing in all of DRM/DRI. KMS on > > the other hand is very attractive as a framebuffer device replacer. It > > is not an easy task to decide on a multimedia user interface for a SoC > > vendor. > > > > Uniting the frameworks within the kernel will likely fail(too big of a > > task) but a common system wide memory manager would for sure make life > > easier enabling the possibility to pass buffers between drivers(and > > user-land as well). In order for No-copy to work on a system level the > > general multimedia infrastructure in User-land (i.e. > > Gstreamer/X11/wayland/stagefright/flingers/etc) must also be aware of > > this memory manager and manage handles accordingly. This > > infrastructure in user-land puts the requirements on the User land API > > (1.). > > > > I know that STE and ARM has a vision to have a hwmem/ump alike API and > > that Linaro is one place to resolve this. As Jesse Barker mentioned > > earlier Linaro has work ongoing on this topic > > ( > https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Projects/Unified > > MemoryManagement) and a V4L2 brainstorming meeting in Warsaw will likely > > bring this up as well. And Gstreamer is also looking at this from a > > user-land point of view. > > I've had a look at HWMEM yesterday. The API seems to go more or less in the > right direction, but the allocator and memory managers are tightly > integrated, > so we'll need to solve that. > > > ARM, STE seems to agree on this, V4L2 maestros seems to agree, > > GStreamer as well(I believe), > > How about Samsung(vcm)? TI(cmem)? Freescale? DRI community? Linus? > > I've asked TI who is responsible for CMEM, I'm waiting for an answer. > > > Jesse! any progress? > > -- > Regards, > > Laurent Pinchart > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
On Tue, Mar 15, 2011 at 9:07 AM, Robert Fekete wrote: > On 8 March 2011 20:23, Laurent Pinchart > wrote: > > Hi Andy, > > > > On Tuesday 08 March 2011 20:12:45 Andy Walls wrote: > >> On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote: > >> > >> [snip] > >> > >> > > > It really shouldn't be that hard to get everyone involved together > >> > > > and settle on a single solution (either based on an existing > >> > > > proposal or create a 'the best of' vendor-neutral solution). > >> > > > >> > > "Single" might be making the problem impossibly hard to solve well. > >> > > One-size-fits-all solutions have a tendency to fall short on meeting > >> > > someone's critical requirement. I will agree that "less than n", > for > >> > > some small n, is certainly desirable. > >> > > > >> > > The memory allocators and managers are ideally satisfying the > >> > > requirements imposed by device hardware, what userspace applications > >> > > are expected to do with the buffers, and system performance. (And > >> > > maybe the platform architecture, I/O bus, and dedicated video > memory?) > >> > > >> > In the embedded world, a very common use case is to capture video data > >> > from an ISP (V4L2+MC), process it in a DSP (V4L2+M2M, tidspbridge, > ...) > >> > and display it on the GPU (OpenGL/ES). We need to be able to share a > >> > data buffer between the ISP and the DSP, and another buffer between > the > >> > DSP and the GPU. If processing is not required, sharing a data buffer > >> > between the ISP and the GPU is required. Achieving zero-copy requires > a > >> > single memory management solution used by the ISP, the DSP and the > GPU. > >> > >> Ah. I guess I misunderstood what was meant by "memory provider" to some > >> extent. > >> > >> So what I read is a common way of providing in kernel persistent buffers > >> (buffer objects? buffer entities?) for drivers and userspace > >> applications to pass around by reference (no copies). Userspace may or > >> may not want to see the contents of the buffer objects. > > > > Exactly. How that memory is allocated in irrelevant here, and we can have > > several different allocators as long as the buffer objects can be managed > > through a single API. That API will probably have to expose buffer > properties > > related to allocation, in order for all components in the system to > verify > > that the buffers are suitable for their needs, but the allocation process > > itself is irrelevant. > > > >> So I understand now why a single solution is desirable. > > > > Exactly, > > It is important to know that there are 3 topics of discussion which > all are a separate topic of its own: > > 1. The actual memory allocator > 2. In-kernel API > 3. Userland API > > Explained: > 1. This is how you acquire the actual physical or virtual memory, > defrag, swap, etc. This can be enhanced by CMA, hotswap, memory > regions or whatever and the main topic for a system wide memory > allocator does not deal much with how this is done. > 2. In-kernel API is important from a device driver point of view in > order to resolve buffers, pin memory when used(enable defrag when > unpinned) > 3. Userland API deals with alloc/free, import/export(IPC), security, > and set-domain capabilities among others and is meant to pass buffers > between processes in userland and enable no-copy data paths. > > We need to resolve 2. and 3. > > GEM/TTM is mentioned in this thread and there is an overlap of what is > happening within DRM/DRI/GEM/TTM/KMS and V4L2. The whole idea behind > DRM is to have one device driver for everything (well at least 2D/3D, > video codecs, display output/composition), while on a SoC all this is > on several drivers/IP's. A V4L2 device cannot resolve a GEM handle. > GEM only lives inside one DRM device (AFAIK). GEM is also mainly for > "dedicated memory-less" graphics cards while TTM mainly targets > advanced Graphics Card with dedicated memory. From a SoC point of view > DRM looks very "fluffy" and not quite slimmed for an embedded device, > and you cannot get GEM/TTM without bringing in all of DRM/DRI. KMS on > the other hand is very attractive as a framebuffer device replacer. It > is not an easy task to decide on a multimedia user interface for a SoC > vendor. > > Uniting the fr
Re: Yet another memory provider: can linaro organize a meeting?
Hi all, Here's what I've cobbled together tentatively from prior threads involving linaro-dev as well as folks from ARM, Samsung and ST-E: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Projects/UnifiedMemoryManagement The current goals within the graphics working group are to map these API requirements to extant allocator functionality; in particular, we are looking at the current UMP drop with respect to TTM (it's what we have immediately to hand, but would be happy doing similar exercises with HWMEM, etc.). From there we can work out what needs to be done to add appropriate support to TTM (or another allocator). Please let me know if I've missed anything. cheers, Jesse On Tue, Mar 8, 2011 at 6:01 AM, Andy Walls wrote: > On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote: > > Hi all, > > > > We had a discussion yesterday regarding ways in which linaro can assist > > V4L2 development. One topic was that of sorting out memory providers like > > GEM and HWMEM. > > > > Today I learned of yet another one: UMP from ARM. > > > > > http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/ > > > > This is getting out of hand. I think that organizing a meeting to solve > this > > mess should be on the top of the list. Companies keep on solving the same > > problem time and again and since none of it enters the mainline kernel > any > > driver using it is also impossible to upstream. > > > > All these memory-related modules have the same purpose: make it possible > to > > allocate/reserve large amounts of memory and share it between different > > subsystems (primarily framebuffer, GPU and V4L). > > I'm not sure that's the entire story regarding what the current > allocators for GPU do. TTM and GEM create in kernel objects that can be > passed between applications. TTM apparently has handling for VRAM > (video RAM). GEM uses anonymous userspace memory that can be swapped > out. > > TTM: > http://lwn.net/Articles/257417/ > http://www.x.org/wiki/ttm > > http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=mm.pdf > > http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=xdevconf2006.pdf > > GEM: > http://lwn.net/Articles/283798/ > > GEM vs. TTM: > http://lwn.net/Articles/283793/ > > > The current TTM and GEM allocators appear to have API and buffer > processing and management functions tied in with memory allocation. > > TTM has fences for event notification of buffer processing completion. > (maybe something v4l2 can do with v4l2_events?) > > GEM tries avoid mapping buffers to userspace. (sounds like the v4l2 mem > to mem API?) > > > Thanks to the good work of developers on the LMML in the past year or > two, V4L2 has separated out some of that functionality from video buffer > allocation: > >video buffer queue management and userspace access (videobuf2) >memory to memory buffer transformation/movement (m2m) >event notification (VIDIOC_SUBSCRIBE_EVENT) > >http://lwn.net/Articles/389081/ >http://lwn.net/Articles/420512/ > > > > It really shouldn't be that hard to get everyone involved together and > settle > > on a single solution (either based on an existing proposal or create a > 'the > > best of' vendor-neutral solution). > > > "Single" might be making the problem impossibly hard to solve well. > One-size-fits-all solutions have a tendency to fall short on meeting > someone's critical requirement. I will agree that "less than n", for > some small n, is certainly desirable. > > The memory allocators and managers are ideally satisfying the > requirements imposed by device hardware, what userspace applications are > expected to do with the buffers, and system performance. (And maybe the > platform architecture, I/O bus, and dedicated video memory?) > > > > > I am currently aware of the following solutions floating around the net > > that all solve different parts of the problem: > > > > In the kernel: GEM and TTM. > > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM. > > Prior to a meeting one would probably want to capture for each > allocator: > > 1. What are the attributes of the memory allocated by this allocator? > > 2. For what domain was this allocator designed: GPU, video capture, > video decoder, etc. > > 3. How are applications expected to use objects from this allocator? > > 4. What are the estimated sizes and lifetimes of objects that would be > allocated this allocator? > > 5. Beyond memory allocation, what other functionality is built into this > allocator: buffer queue management, event notification, etc.? > > 6. Of the requirements that this allocator satisfies, what are the > performance critical requirements? > > > Maybe there are better question to ask. > > Regards, > Andy > > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/l
Re: [RFC] Linaro Toolchain for Android and NDK
FWIW, skia certainly isn't android only and, at least for the purposes of getting the validation side of things up and running, could be run on a non-android build (Jammy is likely doing something like this for his work, though not oriented at abrek at the moment). Of course, I could be over-simplifying here ;-). cheers, Jesse On Fri, Feb 25, 2011 at 9:05 AM, Paul Larson wrote: > > Inside Google, there is a dedicated compiler team working on GNU > >> > Toolchain for various purposes including server-side >> > computing, Android, Chrome OS, etc. Google engineers submit patches to >> > upstream for public review and maintain the >> > toolchain for Android. Along with each Android Open Source Prokect >> > (AOSP) release, there is a special branch in korg >> > GIT [2] for hosting the GPL'd toolchain source code modified by >> > Google. Usually, file "README.google" mentioned the >> > summary, but it is not developer friendly because several changes were >> > done within one GIT commit. >> > >> > Please refer to wiki for details: >> >https://wiki.linaro.org/Platform/Android/UpstreamToolchain >> > >> >> thats a good wiki page. thanks for the content. If I read the skia >> example correctly, we could add a test to our "normal" abrek testsuite >> that uses our daily android toolchain and run the skia benchmark? e.g. >> we could start doing this benchmarking even without having a >> validation solution ready for android targets? >> >> Please let's talk to Paul how we can get the android toolchain to >> /opt/android as part of abrek and lets try to add this to our abrek >> testsuites. Until we have daily toolchain builds it would be OK to >> download the android toolchain tarball from a fixed place from >> people.linaro.org I guess. >> > I think there's going to be more to it than that. My understand based on > some quick research about skia is that it is a 2d graphics benchmark and > needs to be run under android itself. Which means we first need android > booting on our hardware. Am I mistaken about this? > > Do we have any idea how far we are away from having linaro android images? > > Thanks, > Paul Larson > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i.MX23/28 framebuffer driver
Speaking for the Linaro graphics working group, I think it's great. And, I think you're right, that if enough of the KMS support in xf86-video-* is similar enough (I was only aware of intel and nouveau supporting it properly at current), pulling it out into a common layer would make it easier to support in new drivers (including fbdev). cheers, Jesse On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann wrote: > On Tuesday 15 February 2011, Clark, Rob wrote: > > I'd been experimenting a bit on the side w/ the DRM driver framework ( > > > http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu > > ), but had to add a good chunk of mostly boilerplate code to our xorg > > driver in order just to test it. Maybe some generic support for KMS > > in xf86-video-fbdev would have made this easier to develop the kernel > > part without in parallel having to implement the userspace part. I'm > > not sure if this is the sort of thing the linaro-wg has in mind? > > I'm not sure what the the linaro multimedia wg thinks of this, but the > kernel code you linked looks like it's doing exactly the right thing. > >Arnd > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Notes & Actions: Linaro Graphics Working Group - Feb 09, 2011
Rob, It is certainly analogous to the DRM access control interfaces, and I would expect that access to memory objects from the graphics stack would go through those interfaces (i.e. Xorg/EGL calls libdrm, calls DRM kernel ioctl, calls memory manger inside the kernel), but we need to make sure we have equivalent interfaces setup for non-graphics applications to make sure that all access control policy is honored. So, in short, yes, there's a connection :-). cheers, Jesse On Tue, Feb 15, 2011 at 5:27 AM, Clark, Rob wrote: > On Fri, Feb 11, 2011 at 7:47 AM, Alexandros Frantzis > wrote: > > > > * First version of Unified Memory Management position: > > > https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Projects/UnifiedMemoryManagement > > btw, the access control aspect of this sort of reminds me of the DRM > driver infrastructure, and authentication between direct rendering > client and x-server (or whoever the DRM master is).. > > I wonder if there is, or should be, a connection.. > > BR, > -R > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New dial-in number for conference calls
In addition to the India numbers that Alexander mentioned on another part of this thread, we would need Greece and Korea numbers to switch the graphics working group call over. cheers, Jesse On Mon, Jan 24, 2011 at 8:45 AM, Loïc Minier wrote: >Hi folks > > (Sorry for the late notice, we were caught by surprize by the speed of > this move) > > The conference system for phone calls moved to new dial-in numbers this > week; the conf room numbers remain the same as well as leader pins, but > the dial in change; this is a non-exhaustive list: > UK Local+44 207 630 2405 > UK Freephone0800 026 0166 > US Local+1 781 761 9450 > US Toll Free1 866 352 2709 > Brazil 0800 881 0038 > Canada 1 866 352 2710 > Finland 800 523 103 > France 0 805 980 044 > Germany 800 589 0993 > New Zealand 800 452 290 > Taiwan 0800 265 855 > China (North) 10 800 152 1873 > China (South) 10 800 852 1873 > India 000 800 100 7944 > > I was told the number for India doesn't work; I'll try finding another > one. > > Most calls should have moved to these new numbers, if not please update > the calendar invites! > > Thanks > -- > Loïc Minier > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: how to get hardware accelerated video and OpenGL ES for OMAP3530 (IGEPv2 board)? (noob alert)
Hi Jorg, The availability of graphics drivers is obviously quite a hot topic at the moment. For your OMAP3 board, you are probably better off sticking with the ubuntu packages (you'll need to add multiverse in order to find the various '*-sgx-omap3' packages) as that will get you up and running fastest. We are working, through the landing teams at Linaro, to get drivers integrated and redistributable, but that is still a work in progress and does not include OMAP3 for this cycle. In the short term, these would also all be binary-only proprietary drivers (as the ones in the ubuntu packages for omap3 are). The free driver question is a much longer term project, though it has begun for us this cycle. I hope this helps you out. cheers, Jesse 2011/1/20 Jörg Hohensohn > Hello, > > This is my first post, I'm a complete noop to Linaro, discovered it > yesterday. Needing to run OpenGL ES applications and media playback, I was > excited to find e.g. this one: > > http://www.youtube.com/watch?v=yhglD0mJiLk > (under Linaro, GStreamer playing a video by DSP in fullscreen) > > and this one, admittedly not Linaro but Debian: > http://www.youtube.com/watch?v=Qaypv-JhEVI > (Quake3 using hardware OpenGL ES) > > During first and promising own experiments, I was surprised to find that > OpenGL acceleration and A/V decoding by hardware don't seem to be part of > the Linaro hardware package. Does anybody have that integrated, or how would > I do about that? > > Interestingly, TI has just released those supporting components in a fresh > version: > http://focus.ti.com/docs/toolsw/folders/print/linuxdvsdk-dm37x.html > But they come with an older kernel. To my understanding, the TI code would > have to be recompiled with the Linaro kernel? > > > Thanks for answers, > Jörg > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Dynamic hwcaps
Dave, For the case of NEON and its use in graphics libraries, we are certainly pushing explicitly for runtime detection. However, this tends to be done by detecting the presence of NEON at initialization time, rather than at each path invocation (to avoid rescanning /proc/self/auxv). Are you saying that the init code could still detect NEON this way, but there would need to be additional checks when taking individual paths? cheers, Jesse On Fri, Dec 3, 2010 at 8:28 AM, Dave Martin wrote: > Hi all, > > I'd be interested in people's views on the following idea-- feel free > to ignore if it doesn't interest you. > > > For power-management purposes, it's useful to be able to turn off > functional blocks on the SoC. > > For on-SoC peripherals, this can be managed through the driver > framework in the kernel, but for functional blocks of the CPU itself > which are used by instruction set extensions, such as NEON or other > media accelerators, it would be interesting if processes could adapt > to these units appearing and disappearing at runtime. This would mean > that user processes would need to select dynamically between different > implementations of accelerated functionality at runtime. > > This allows for more active power management of such functional > blocks: if the CPU is not fully loaded, you can turn them off -- the > kernel can spot when there is significant idle time and do this. If > the CPU becomes fully loaded, applications which have soft-realtime > constraints can notice this and switch to their accelerated code > (which will cause the kernel to switch the functional unit(s) on). > Or, the kernel can react to increasing CPU load by speculatively turn > it on instead. This is analogous to the behaviour of other power > governors in the system. Non-aware applications will still work > seamlessly -- these may simply run accelerated code if the hardware > supports it, causing the kernel to turn the affected functional > block(s) on. > > In order for this to work, some dynamic status information would need > to be visible to each user process, and polled each time a function > with a dynamically switchable choice of implementations gets called. > You probably don't need to worry about race conditions either-- if the > process accidentally tries to use a turned-off feature, you will take > a fault which gives the kernel the chance to turn the feature back on. > Generally, this should be a rare occurrence. > > > The dynamic feature status information should ideally be per-CPU > global, though we could have a separate copy per thread, at the cost > of more memory. It can't be system-global, since different CPUs may > have a different set of functional blocks active at any one time -- > for this reason, the information can't be stored in an existing > mapping such as the vectors page. Conversely, existing mechanisms > such sysfs probably involve too much overhead to be polled every time > you call copy_pixmap() or whatever. > > Alternatively, each thread could register a userspace buffer (a single > word is probably adequate) into which the CPU pokes the hardware > status flags each time it returns to userspace, if the hardware status > has changed or if the thread has been migrated. > > Either of the above approaches could be prototyped as an mmap'able > driver, though this may not be the best approach in the long run. > > > Does anyone have a view on whether this is a worthwhile idea, or what > the best approach would be? > > Cheers > ---Dave > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Flash cards
That's fantastic. Thanks. cheers, Jesse On Thu, Oct 21, 2010 at 12:44 AM, Michael Hope wrote: > I'm still terrible with names so I've updated my flash cards for the > summit. See: > http://people.linaro.org/~michaelh/boo/ > > Click on the image to show the persons name and role. Click again to > move on. The site is iPhone friendly. > > The site is generated by parsing the engineering contacts page and > pulling out the images. See: > https://code.launchpad.net/~michaelh1/+junk/boo > > for the terrible, terrible code. > > -- Michael > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: clutk status update 2010/09/14
On Wed, 2010-09-15 at 20:58 +0800, Jammy Zhou wrote: > After debugging into glBindFramebuffer, the error is not for this API > call. And the GL_INVALID_OPERATION error should be caused by previous > opengl call, for which CheckGLError is not called. Glad to hear it. It would otherwise have suggested a potential implementation problem as the spec doesn't define that error for that situation. cheers, Jesse > > Regards, > Jammy > > On Wed, Sep 15, 2010 at 9:19 AM, Jammy Zhou > wrote: > Hi Jesse, > > Thanks for your point. I can confirm that the fbo extension is > available there for this functionality, and there is no such > error messages when call the same function in other clutk test > cases. And yes, the run-time check for the fbo capability is > not implemented, it is assumed that this extension is > supported by default now (It should not be a problem for > opengl es2.0 driver with fbo extension supported, I think). > > Regards, > Jammy > > > > On Wed, Sep 15, 2010 at 5:22 AM, Jesse Barker > wrote: > Jammy, > > With respect to the CheckGLError assertion in > test-clutk-perf, assuming > that glGetError is called per OpenGL entry point (i.e. > you are not > seeing an error triggered by another call), the only > way you should be > seeing an invalid operation when setting framebuffer > binding(s) back to > the default (glBindFramebuffer(GL_FRAMEBUFFER, 0)) is > if the framebuffer > object extension functionality is simply not there > (your OpenGL or GLES > implementation is too old). I notice that the > 'WITH_GLES' paths have > fewer checks for capabilities. Is it possible that > the code is simply > not checking at the moment? > > cheers, > Jesse > > > On Tue, 2010-09-14 at 17:23 +0800, Jammy Zhou wrote: > > Hi Alexander, > > > > On Tue, Sep 14, 2010 at 4:31 PM, Alexander Sack > > > wrote: > > On Tue, Sep 14, 2010 at 9:38 AM, Jammy Zhou > > wrote: > > > > > > Issues Fixed: > > > + Normalize clutter vetex positions to > adapt to the vertex > > shader > > > + Use GL_TRIANGLE_FAN to implement > original used GL_QUADS > > primitive, which > > > is not supported by gles2 > > > + Comment out cogl_flush() call in some > functions (such as > > > ctk_effect_blur_paint) to make sure > following gles2 > > rendering can be shown > > > + Fix render to cached texture problems > > > > > > very nice. > > > > is the cogl_flash call comment something we > want to keep or > > does that > > show an underlying issue we should try to > fix? > > > > [jammy] Because cogl_flush is implemented based on > fixed pipeline, if > > we want to really fix it, we may need to use cogl > for gles2 support in > > clutk, I think. So I just comment out them in some > proper places for a > > workaround. > > > > > > > > > > > > Issues Left: > > > + run test-clutk, there is crash at > > "/Effect/Animation/Animation" test > > > suite. This issue has already been > reported by Alexandros, > > see > > > > https://bugs.
Re: clutk status update 2010/09/14
Jammy, With respect to the CheckGLError assertion in test-clutk-perf, assuming that glGetError is called per OpenGL entry point (i.e. you are not seeing an error triggered by another call), the only way you should be seeing an invalid operation when setting framebuffer binding(s) back to the default (glBindFramebuffer(GL_FRAMEBUFFER, 0)) is if the framebuffer object extension functionality is simply not there (your OpenGL or GLES implementation is too old). I notice that the 'WITH_GLES' paths have fewer checks for capabilities. Is it possible that the code is simply not checking at the moment? cheers, Jesse On Tue, 2010-09-14 at 17:23 +0800, Jammy Zhou wrote: > Hi Alexander, > > On Tue, Sep 14, 2010 at 4:31 PM, Alexander Sack > wrote: > On Tue, Sep 14, 2010 at 9:38 AM, Jammy Zhou > wrote: > > > > Issues Fixed: > > + Normalize clutter vetex positions to adapt to the vertex > shader > > + Use GL_TRIANGLE_FAN to implement original used GL_QUADS > primitive, which > > is not supported by gles2 > > + Comment out cogl_flush() call in some functions (such as > > ctk_effect_blur_paint) to make sure following gles2 > rendering can be shown > > + Fix render to cached texture problems > > > very nice. > > is the cogl_flash call comment something we want to keep or > does that > show an underlying issue we should try to fix? > > [jammy] Because cogl_flush is implemented based on fixed pipeline, if > we want to really fix it, we may need to use cogl for gles2 support in > clutk, I think. So I just comment out them in some proper places for a > workaround. > > > > > > > Issues Left: > > + run test-clutk, there is crash at > "/Effect/Animation/Animation" test > > suite. This issue has already been reported by Alexandros, > see > > https://bugs.launchpad.net/clutk/+bug/614415, and it should > be an upstream > > problem. > > > neil replied in the other mail thread and has a patch for > clutter that > we should try. maybe see if that helps > > [jammy] I have tried the patch from Neil, and it works, but now there > is the same issue for glBindFramebuffer as mentioned below at > "/Effect/Animation/Signals" test suite when run test-clutk. > > > > > + when run "test-clutk-perf 0 10 125 5 single animated blur > 0.3.2 GMA950 2.1 > > 1 10", crash happens with following error message. The error > happens when > > call glBindFramebuffer (GL_FRAMEBUFFER, 0). > > Clutk-WARNING **: [CheckGLError] GL_INVALID_OPERATION error > in File > > ./ctk-render-target.c at line: 581 > > > Is this a regression from our gles port? e.g. if you run the > same > command with desktop gl does it work? > > [jammy] This is a regression from our gles port. > > > > + the actor painting (i.e, "paint_func(actor);" in > ctk_effect_blur_paint) > > seems independent from other gles2 rendering, and it is not > rendered into > > cached texture for later display. This means that we cannot > add special > > effects to the actor. > > > Do you think its a bug that it is independent from other > rendering? > what happens if we try to fix this? > > [jammy] I think it is not a bug, but incompatibility between cogl > rendering and our gles2 rendering. > > > > > -- > > - Alexander > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- 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. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
