On Wed, Mar 16, 2011 at 3:14 AM, Kyungmin Park kmp...@infradead.org 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
On Monday 21 March 2011 19:03:38 Hans Verkuil wrote:
On Wednesday, March 16, 2011 09:14:54 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
On Wednesday, March 16, 2011 09:14:54 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
Sorry but I feel the discussion is a bit off the point. We're not
going to compare the pros and cons of current code (GEM/TTM, HWMEM,
UMP, CMA, VCM, CMEM, PMEM, etc.)
The real problem is to find a suitable unified memory management
module for various kinds of HW components (including CPU, VPU,
On Wed, Mar 16, 2011 at 4:37 PM, Li Li eggon...@gmail.com wrote:
Sorry but I feel the discussion is a bit off the point. We're not
going to compare the pros and cons of current code (GEM/TTM, HWMEM,
UMP, CMA, VCM, CMEM, PMEM, etc.)
The real problem is to find a suitable unified memory
On Tuesday 15 March 2011 17:07:10 Robert Fekete wrote:
On 8 March 2011 20:23, Laurent Pinchart wrote:
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
Hi Alex,
On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote:
[snip]
FWIW, I have yet to see any v4l developers ever email the dri mailing
list while discussing GEM, TTM, or the DRM, all the while conjecturing
on aspects of it they admit to not fully understanding. For future
reference,
On Wed, Mar 16, 2011 at 4:52 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Alex,
On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote:
[snip]
FWIW, I have yet to see any v4l developers ever email the dri mailing
list while discussing GEM, TTM, or the DRM, all the while
On Wed, Mar 16, 2011 at 3:37 AM, Li Li eggon...@gmail.com wrote:
Sorry but I feel the discussion is a bit off the point. We're not
going to compare the pros and cons of current code (GEM/TTM, HWMEM,
UMP, CMA, VCM, CMEM, PMEM, etc.)
The real problem is to find a suitable unified memory
Hi Alex,
On Wednesday 16 March 2011 17:00:03 Alex Deucher wrote:
On Wed, Mar 16, 2011 at 4:52 AM, Laurent Pinchart wrote:
On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote:
[snip]
FWIW, I have yet to see any v4l developers ever email the dri mailing
list while discussing GEM,
Hi Alex,
On Wednesday 16 March 2011 17:09:45 Alex Deucher wrote:
On Wed, Mar 16, 2011 at 3:37 AM, Li Li eggon...@gmail.com wrote:
Sorry but I feel the discussion is a bit off the point. We're not
going to compare the pros and cons of current code (GEM/TTM, HWMEM,
UMP, CMA, VCM, CMEM, PMEM,
On 8 March 2011 20:23, Laurent Pinchart
laurent.pinch...@ideasonboard.com 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
On Tue, Mar 15, 2011 at 12:07 PM, Robert Fekete
robert.fek...@linaro.org wrote:
On 8 March 2011 20:23, Laurent Pinchart
laurent.pinch...@ideasonboard.com 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]
On Tue, Mar 8, 2011 at 12:23 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Tuesday, March 08, 2011 15:01:10 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
On Tue, Mar 8, 2011 at 9:01 AM, Andy Walls awa...@md.metrocast.net 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
On Thu, Mar 10, 2011 at 03:14:11PM +0100, Marek Szyprowski wrote:
Hello,
On Tuesday, March 08, 2011 9:14 AM Hans Verkuil wrote:
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
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.
Dear Jonghun,
It's also helpful to explain what's the original purpose of UMP (for
GPU, MALI) and what's the goal of UMP usage for multimedia stack.
Especially, what's the final goal of UMP from LSI.
Also consider the previous GPU memory management program, e.g., SGX.
Thank you,
Kyungmin Park
Hi Andy,
On Tuesday 08 March 2011 15:01:10 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.
On Tuesday, March 08, 2011 15:01:10 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.
Hi LAurent,
On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote:
Hi Andy,
[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).
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
Hi Hans,
On Tue, 2011-03-08 at 18:23 +0100, Hans Verkuil wrote:
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
23 matches
Mail list logo
