> There is a fully functional unichrome DRM on top of TTM, that together with
> the 3D driver in mesa's openchrome branch worked like a charm (even
> outperformed Intel's i965 with identical CPU at the time).
> Problem was that it was not backwards compatible with via's old drm.
>
> It should ser
On 10/03/2011 09:14 PM, Alan Cox wrote:
>> the front buffer. The problem was the buffer offset for the second
>> allocation was the same as the VQ buffer. I'm stump to what I'm doing
>> wrong, so does anyone have a idea?
>>
> I gave up trying to understand TTM (they don't make happy pills tha
On 10/04/2011 01:07 AM, Alan Cox wrote:
>> Thats fine as long as you don't want to do acceleration or object
>> migration between GTT
>> and VRAM type memory. Now I expect when you give out this advice you
>>
> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> It's
> >> Without code to look at we all can start guessing :) my guess is either
> >> you are not using the proper offset field or you are allocating from
> >> different memory pool.
> >
> > http://cgit.freedesktop.org/~jsimmons/drm-openchrome
> >
>
> >From quick glimpse ttm_bo_allocate in via/init_t
> On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox wrote:
> >> the front buffer. The problem was the buffer offset for the second
> >> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> >> wrong, so does anyone have a idea?
> >
> > I gave up trying to understand TTM (they don't make
> >> > Thats fine as long as you don't want to do acceleration or object
> >> > migration between GTT
> >> > and VRAM type memory. Now I expect when you give out this advice you
> >>
> >> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> >> It's all effectively in the GA
> > Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>
> That depends on your libkms for the device. You can allocate a one bit
> deep object if you want. Reading libkms source is probably what you need
> if
> > ? ? ? ?Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
> > of POS devices. That chipset only supports monochrome cursors.
>
> As far as I know, the KMS cursor API doesn't really care what type of
> cursors a
> > Thats fine as long as you don't want to do acceleration or object
> > migration between GTT
> > and VRAM type memory. Now I expect when you give out this advice you
>
> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> It's all effectively in the GART with the 'stol
> There is a fully functional unichrome DRM on top of TTM, that together with
> the 3D driver in mesa's openchrome branch worked like a charm (even
> outperformed Intel's i965 with identical CPU at the time).
> Problem was that it was not backwards compatible with via's old drm.
>
> It should ser
On 10/03/2011 09:14 PM, Alan Cox wrote:
the front buffer. The problem was the buffer offset for the second
allocation was the same as the VQ buffer. I'm stump to what I'm doing
wrong, so does anyone have a idea?
I gave up trying to understand TTM (they don't make happy pills that big)
and
On 10/04/2011 01:07 AM, Alan Cox wrote:
Thats fine as long as you don't want to do acceleration or object
migration between GTT
and VRAM type memory. Now I expect when you give out this advice you
Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
It's all effective
On Tue, Oct 4, 2011 at 9:45 AM, James Simmons wrote:
>
>> > ? ? ? ?Second question I have is how are monochrome cursor images
>> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>> > of POS devices. That chipset only supports monochrome cursors.
>>
>> As far as I know, the
On Tue, Oct 4, 2011 at 9:42 AM, James Simmons wrote:
>
>> > Thats fine as long as you don't want to do acceleration or object
>> > migration between GTT
>> > and VRAM type memory. Now I expect when you give out this advice you
>>
>> Yes but the VIA doesn't if I recall correctly have any 'VRAM type
> >> Without code to look at we all can start guessing :) my guess is either
> >> you are not using the proper offset field or you are allocating from
> >> different memory pool.
> >
> > http://cgit.freedesktop.org/~jsimmons/drm-openchrome
> >
>
> >From quick glimpse ttm_bo_allocate in via/init_t
> On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox wrote:
> >> the front buffer. The problem was the buffer offset for the second
> >> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> >> wrong, so does anyone have a idea?
> >
> > I gave up trying to understand TTM (they don't make
> >> > Thats fine as long as you don't want to do acceleration or object
> >> > migration between GTT
> >> > and VRAM type memory. Now I expect when you give out this advice you
> >>
> >> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> >> It's all effectively in the GA
> > Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>
> That depends on your libkms for the device. You can allocate a one bit
> deep object if you want. Reading libkms source is probably what you need
> if
On Tue, Oct 4, 2011 at 9:45 AM, James Simmons wrote:
>
>> > Second question I have is how are monochrome cursor images
>> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>> > of POS devices. That chipset only supports monochrome cursors.
>>
>> As far as I know, the
On Tue, Oct 4, 2011 at 9:42 AM, James Simmons wrote:
>
>> > Thats fine as long as you don't want to do acceleration or object
>> > migration between GTT
>> > and VRAM type memory. Now I expect when you give out this advice you
>>
>> Yes but the VIA doesn't if I recall correctly have any 'VRAM type
> > Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
> > of POS devices. That chipset only supports monochrome cursors.
>
> As far as I know, the KMS cursor API doesn't really care what type of
> cursors a
> > Thats fine as long as you don't want to do acceleration or object
> > migration between GTT
> > and VRAM type memory. Now I expect when you give out this advice you
>
> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> It's all effectively in the GART with the 'stol
> Thats fine as long as you don't want to do acceleration or object
> migration between GTT
> and VRAM type memory. Now I expect when you give out this advice you
Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
It's all effectively in the GART with the 'stolen' pages pre
> > Hi!
> >
> > ? ? ? ?I been working on updating the VIA kernel driver to using KMS
> > and TTM. So this weekend I started to implement a couple of buffer
> > allocations internally to the driver from the video ram. So the first
> > buffer I allocated was not the front buffer from the video vram
On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox wrote:
>> the front buffer. The problem was the buffer offset for the second
>> allocation was the same as the VQ buffer. I'm stump to what I'm doing
>> wrong, so does anyone have a idea?
>
> I gave up trying to understand TTM (they don't make happy pills t
> the front buffer. The problem was the buffer offset for the second
> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> wrong, so does anyone have a idea?
I gave up trying to understand TTM (they don't make happy pills that big)
and used GEM and a simple allocator. The pri
Hi!
I been working on updating the VIA kernel driver to using KMS
and TTM. So this weekend I started to implement a couple of buffer
allocations internally to the driver from the video ram. So the first
buffer I allocated was not the front buffer from the video vram but a
virtual queu
> Thats fine as long as you don't want to do acceleration or object
> migration between GTT
> and VRAM type memory. Now I expect when you give out this advice you
Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
It's all effectively in the GART with the 'stolen' pages pre
On Mon, Oct 3, 2011 at 3:37 PM, James Simmons wrote:
>
>> > Hi!
>> >
>> > ? ? ? ?I been working on updating the VIA kernel driver to using KMS
>> > and TTM. So this weekend I started to implement a couple of buffer
>> > allocations internally to the driver from the video ram. So the first
>> > buf
On Mon, Oct 3, 2011 at 3:01 PM, James Simmons wrote:
>
> Hi!
>
> ? ? ? ?I been working on updating the VIA kernel driver to using KMS
> and TTM. So this weekend I started to implement a couple of buffer
> allocations internally to the driver from the video ram. So the first
> buffer I allocated wa
On Mon, Oct 3, 2011 at 3:01 PM, James Simmons wrote:
>
> Hi!
>
> ? ? ? ?I been working on updating the VIA kernel driver to using KMS
> and TTM. So this weekend I started to implement a couple of buffer
> allocations internally to the driver from the video ram. So the first
> buffer I allocated wa
On Mon, Oct 3, 2011 at 3:37 PM, James Simmons wrote:
>
>> > Hi!
>> >
>> > I been working on updating the VIA kernel driver to using KMS
>> > and TTM. So this weekend I started to implement a couple of buffer
>> > allocations internally to the driver from the video ram. So the first
>> > buf
On Mon, Oct 3, 2011 at 3:01 PM, James Simmons wrote:
>
> Hi!
>
> I been working on updating the VIA kernel driver to using KMS
> and TTM. So this weekend I started to implement a couple of buffer
> allocations internally to the driver from the video ram. So the first
> buffer I allocated wa
> > Hi!
> >
> > I been working on updating the VIA kernel driver to using KMS
> > and TTM. So this weekend I started to implement a couple of buffer
> > allocations internally to the driver from the video ram. So the first
> > buffer I allocated was not the front buffer from the video vram
On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox wrote:
>> the front buffer. The problem was the buffer offset for the second
>> allocation was the same as the VQ buffer. I'm stump to what I'm doing
>> wrong, so does anyone have a idea?
>
> I gave up trying to understand TTM (they don't make happy pills t
> the front buffer. The problem was the buffer offset for the second
> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> wrong, so does anyone have a idea?
I gave up trying to understand TTM (they don't make happy pills that big)
and used GEM and a simple allocator. The pri
On Mon, Oct 3, 2011 at 3:01 PM, James Simmons wrote:
>
> Hi!
>
> I been working on updating the VIA kernel driver to using KMS
> and TTM. So this weekend I started to implement a couple of buffer
> allocations internally to the driver from the video ram. So the first
> buffer I allocated wa
Hi!
I been working on updating the VIA kernel driver to using KMS
and TTM. So this weekend I started to implement a couple of buffer
allocations internally to the driver from the video ram. So the first
buffer I allocated was not the front buffer from the video vram but a
virtual queu
Hi!
So I recently got my new motherboard with a AGP port for continued
development of 3Dfx KMS. Well this board comes with a built in VIA
based IGP. Well that chipset is poorly supported so I started to work on
the via drm driver. Currently I'm porting it to the TTM infrastructure.
Hi!
So I recently got my new motherboard with a AGP port for continued
development of 3Dfx KMS. Well this board comes with a built in VIA
based IGP. Well that chipset is poorly supported so I started to work on
the via drm driver. Currently I'm porting it to the TTM infrastructure.
Now that I'm adding in TTM support to my 3Dfx driver I have a questions.
First I noticed in almost every driver for ttm initialization that two
struct ttm_global_reference global_ref are allocated. One for TTM_GLOBAL_TTM_MEM
and one for TTM_GLOBAL_TTM_BO. For a graphics card with only VRAM
On 07/15/2010 11:54 AM, James Simmons wrote:
>
> Now that I'm adding in TTM support to my 3Dfx driver I have a questions.
> First I noticed in almost every driver for ttm initialization that two
> struct ttm_global_reference global_ref are allocated. One for
> TTM_GLOBAL_TTM_MEM
> and one fo
On 07/15/2010 11:54 AM, James Simmons wrote:
Now that I'm adding in TTM support to my 3Dfx driver I have a questions.
First I noticed in almost every driver for ttm initialization that two
struct ttm_global_reference global_ref are allocated. One for TTM_GLOBAL_TTM_MEM
and one for TTM_GL
Now that I'm adding in TTM support to my 3Dfx driver I have a questions.
First I noticed in almost every driver for ttm initialization that two
struct ttm_global_reference global_ref are allocated. One for TTM_GLOBAL_TTM_MEM
and one for TTM_GLOBAL_TTM_BO. For a graphics card with only VRAM
44 matches
Mail list logo
