_
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 al
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, Ma
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 Gree
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 li
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 pro
'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
>
&g
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
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 differe
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 re
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 g
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
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
> s
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 kin
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 expensiv
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
+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
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
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-bas
on 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.
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
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 W
ics-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 C
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 GetP
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 so
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 fu
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 ;-).
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 embed
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 embed
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.
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 an
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 u
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.glbenchm
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 multime
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 me
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 the
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-simpl
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
s
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
h
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, w
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 f
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 say
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
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,
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 defau
44 matches
Mail list logo
