On Mon, Jan 09, 2012 at 11:56:20AM -0500, Alex Deucher wrote:
> On Mon, Jan 9, 2012 at 11:49 AM, Daniel Vetter wrote:
> > On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
> >> We would have liked to as well, but with the holidays and internal
> >> review process and people being on va
On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
> We would have liked to as well, but with the holidays and internal
> review process and people being on vacation, and the kernel merge
> window timing it didn't work out this time. Still as Jerome said, our
> VM setup is tightly coupl
On Mon, Jan 09, 2012 at 10:44:15AM -0500, Jerome Glisse wrote:
> On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
> > On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> > > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > > > Hi all,
> > > >
> > > > Meh, I've wa
On Mon, Jan 09, 2012 at 11:56:20AM -0500, Alex Deucher wrote:
> On Mon, Jan 9, 2012 at 11:49 AM, Daniel Vetter wrote:
> > On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
> >> We would have liked to as well, but with the holidays and internal
> >> review process and people being on va
On Mon, Jan 9, 2012 at 11:49 AM, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
>> We would have liked to as well, but with the holidays and internal
>> review process and people being on vacation, and the kernel merge
>> window timing it didn't work out this
On Mon, Jan 9, 2012 at 10:44 AM, Jerome Glisse wrote:
> On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
>> On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
>> > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
>> > > Hi all,
>> > >
>> > > Meh, I've wanted to port
On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
> On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > > Hi all,
> > >
> > > Meh, I've wanted to port the small set of helpers nouveau already has to
> > > handle p
On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > Hi all,
> >
> > Meh, I've wanted to port the small set of helpers nouveau already has to
> > handle per open fd gpu virtual address spaces to core drm, so that I could
> > reus
On Mon, Jan 9, 2012 at 11:49 AM, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
>> We would have liked to as well, but with the holidays and internal
>> review process and people being on vacation, and the kernel merge
>> window timing it didn't work out this
On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
> We would have liked to as well, but with the holidays and internal
> review process and people being on vacation, and the kernel merge
> window timing it didn't work out this time. Still as Jerome said, our
> VM setup is tightly coupl
On Mon, Jan 09, 2012 at 10:44:15AM -0500, Jerome Glisse wrote:
> On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
> > On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> > > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > > > Hi all,
> > > >
> > > > Meh, I've wa
On Mon, Jan 9, 2012 at 10:44 AM, Jerome Glisse wrote:
> On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
>> On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
>> > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
>> > > Hi all,
>> > >
>> > > Meh, I've wanted to port
On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
> On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > > Hi all,
> > >
> > > Meh, I've wanted to port the small set of helpers nouveau already has to
> > > handle p
On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > Hi all,
> >
> > Meh, I've wanted to port the small set of helpers nouveau already has to
> > handle per open fd gpu virtual address spaces to core drm, so that I could
> > reus
On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> Hi all,
>
> Meh, I've wanted to port the small set of helpers nouveau already has to
> handle per open fd gpu virtual address spaces to core drm, so that I could
> reuse them for i915. Just to go one small step towards unifying drivers in
> dr
Hi all,
Meh, I've wanted to port the small set of helpers nouveau already has to
handle per open fd gpu virtual address spaces to core drm, so that I could
reuse them for i915. Just to go one small step towards unifying drivers in
drm/* a bit ...
Looks like I'll have another driver to wrestle or
On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> Hi all,
>
> Meh, I've wanted to port the small set of helpers nouveau already has to
> handle per open fd gpu virtual address spaces to core drm, so that I could
> reuse them for i915. Just to go one small step towards unifying drivers in
> dr
Hi all,
Meh, I've wanted to port the small set of helpers nouveau already has to
handle per open fd gpu virtual address spaces to core drm, so that I could
reuse them for i915. Just to go one small step towards unifying drivers in
drm/* a bit ...
Looks like I'll have another driver to wrestle or
On 06.01.2012 15:12, Alex Deucher wrote:
> 2012/1/6 Christian K?nig:
>> On -10.01.-28163 20:59, alexdeucher at gmail.com wrote:
>> [SNIP]
>>
>>> #define RADEON_CHUNK_ID_RELOCS0x01
>>> #define RADEON_CHUNK_ID_IB0x02
>>> #define RADEON_CHUNK_ID_FLAGS 0x03
>>>
>>> /* The first dwor
On -10.01.-28163 20:59, alexdeucher at gmail.com wrote:
[SNIP]
> #define RADEON_CHUNK_ID_RELOCS 0x01
> #define RADEON_CHUNK_ID_IB 0x02
> #define RADEON_CHUNK_ID_FLAGS 0x03
>
> /* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags: */
> #define RADEON_CS_KEEP_T
On Fri, Jan 6, 2012 at 3:11 AM, wrote:
> From: Jerome Glisse
>
> Virtual address space are per drm client (opener of /dev/drm).
> Client are in charge of virtual address space, they need to
> map bo into it by calling DRM_RADEON_GEM_VA ioctl.
>
> First 16M of virtual address space is reserved by
2012/1/6 Christian K?nig :
> On 06.01.2012 15:12, Alex Deucher wrote:
>>
>> 2012/1/6 Christian K?nig:
>>>
>>> On -10.01.-28163 20:59, alexdeucher at gmail.com wrote:
>>> [SNIP]
>>>
?#define RADEON_CHUNK_ID_RELOCS ? ? ? ?0x01
?#define RADEON_CHUNK_ID_IB ? ?0x02
?#define RADEON_CHUNK_I
On Fri, Jan 6, 2012 at 5:09 AM, Dave Airlie wrote:
> On Fri, Jan 6, 2012 at 3:11 AM, ? wrote:
>> From: Jerome Glisse
>>
>> Virtual address space are per drm client (opener of /dev/drm).
>> Client are in charge of virtual address space, they need to
>> map bo into it by calling DRM_RADEON_GEM_VA i
2012/1/6 Christian K?nig :
> On -10.01.-28163 20:59, alexdeucher at gmail.com wrote:
> [SNIP]
>
>> ?#define RADEON_CHUNK_ID_RELOCS ? ? ? ?0x01
>> ?#define RADEON_CHUNK_ID_IB ? ?0x02
>> ?#define RADEON_CHUNK_ID_FLAGS 0x03
>>
>> ?/* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags:
2012/1/6 Christian König :
> On 06.01.2012 15:12, Alex Deucher wrote:
>>
>> 2012/1/6 Christian König:
>>>
>>> On -10.01.-28163 20:59, alexdeuc...@gmail.com wrote:
>>> [SNIP]
>>>
#define RADEON_CHUNK_ID_RELOCS 0x01
#define RADEON_CHUNK_ID_IB 0x02
#define RADEON_CHUNK_ID_F
On 06.01.2012 15:12, Alex Deucher wrote:
2012/1/6 Christian König:
On -10.01.-28163 20:59, alexdeuc...@gmail.com wrote:
[SNIP]
#define RADEON_CHUNK_ID_RELOCS0x01
#define RADEON_CHUNK_ID_IB0x02
#define RADEON_CHUNK_ID_FLAGS 0x03
/* The first dword of RADEON_CHUNK_ID_FLAGS i
On Fri, Jan 6, 2012 at 5:09 AM, Dave Airlie wrote:
> On Fri, Jan 6, 2012 at 3:11 AM, wrote:
>> From: Jerome Glisse
>>
>> Virtual address space are per drm client (opener of /dev/drm).
>> Client are in charge of virtual address space, they need to
>> map bo into it by calling DRM_RADEON_GEM_VA i
2012/1/6 Christian König :
> On -10.01.-28163 20:59, alexdeuc...@gmail.com wrote:
> [SNIP]
>
>> #define RADEON_CHUNK_ID_RELOCS 0x01
>> #define RADEON_CHUNK_ID_IB 0x02
>> #define RADEON_CHUNK_ID_FLAGS 0x03
>>
>> /* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags:
>>
On -10.01.-28163 20:59, alexdeuc...@gmail.com wrote:
[SNIP]
#define RADEON_CHUNK_ID_RELOCS0x01
#define RADEON_CHUNK_ID_IB0x02
#define RADEON_CHUNK_ID_FLAGS 0x03
/* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags: */
#define RADEON_CS_KEEP_TILING_FLAGS 0x
On Fri, Jan 6, 2012 at 3:11 AM, wrote:
> From: Jerome Glisse
>
> Virtual address space are per drm client (opener of /dev/drm).
> Client are in charge of virtual address space, they need to
> map bo into it by calling DRM_RADEON_GEM_VA ioctl.
>
> First 16M of virtual address space is reserved by
From: Jerome Glisse
Virtual address space are per drm client (opener of /dev/drm).
Client are in charge of virtual address space, they need to
map bo into it by calling DRM_RADEON_GEM_VA ioctl.
First 16M of virtual address space is reserved by the kernel.
Once using 2 level page table we should
31 matches
Mail list logo