KMS and TTM questions

KMS and TTM questions

[James Simmons]

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 queue buffer of about 256K in size. The second allocation was 
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?
	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.

Re: KMS and TTM questions

[Jerome Glisse]

On Mon, Oct 3, 2011 at 3:01 PM, James Simmons <jsimmons@infradead.org> 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 was not the front buffer from the video vram but a
> virtual queue buffer of about 256K in size. The second allocation was
> 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?

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.

>        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.

You can hide the cursor limitation from userspace and pretend supporting
rgb cursor.

Cheers,
Jerome

Re: KMS and TTM questions

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1156 bytes --]


> > 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 queue buffer of about 256K in size. The second allocation was
> > 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?
> 
> 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

> >        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.
> 
> You can hide the cursor limitation from userspace and pretend supporting
> rgb cursor.

So just return -ENXIO in that case.

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS and TTM questions

[Jerome Glisse]

On Mon, Oct 3, 2011 at 3:37 PM, James Simmons <jsimmons@infradead.org> 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 was not the front buffer from the video vram but a
>> > virtual queue buffer of about 256K in size. The second allocation was
>> > 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?
>>
>> 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_ttm.c loose the
TTM_PL_FLAG_NO_EVICT so you vq buffer is not allocated with the no
evict flags, then i guess it got evicted on first bo allocation which
is strange, maybe first bo has some lpfn constraint.

>> >        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.
>>
>> You can hide the cursor limitation from userspace and pretend supporting
>> rgb cursor.
>
> So just return -ENXIO in that case.

No, so far there is no format specification for cursor, so userspace
can send monochrome or you can accept rgb from userspace and convert
to monochrome inside the kernel, but i think it's better to just
assume userspace sends you monochrome.

Cheers,
Jerome

Re: KMS and TTM questions

[James Simmons]

> >> 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_ttm.c loose the
> TTM_PL_FLAG_NO_EVICT so you vq buffer is not allocated with the no
> evict flags, then i guess it got evicted on first bo allocation which
> is strange, maybe first bo has some lpfn constraint.

Tried it and it didn't help. Its the ttm_buffer_object offset that should
vary for each buffer object created from some memory pool. That 
offset is set from bo->mem.mm_node if it is present. Looking at the 
code ttm_bo_init should end up calling ttm_bo_move_buffer which should in 
turn set up the bo->mem.mm_node. I guess I really need to debug the code 
to see what is going on.

Re: KMS and TTM questions

[Alan Cox]

> 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 private allocator GEM change
means you can now use GEM to magic up objects that are in on card or
stolen memory where applicable not just backed in system memory.

> 	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 you've not already done os.

> of POS devices. That chipset only supports monochrome cursors.

Which I think means a modern X will not care about the hardware cursor ?

Alan

Re: KMS and TTM questions

[Dave Airlie]

On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> 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 used GEM and a simple allocator. The private allocator GEM change
> means you can now use GEM to magic up objects that are in on card or
> stolen memory where applicable not just backed in system memory.

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
should also state the limitations your advice leads to.

For a VIA device I think  TTM is necessary as they preallocate large
piece of RAM to VRAM area like 128MB or so and you need to migrate
objects in/out of that area to use it.

Dave.

Re: KMS and TTM questions

[Alan Cox]

> 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 preloaded into
the translation tables by the BIOS at vga init time.

It has fake VRAM type memory but thats really an illusion (although one
the driver seems to like to keep up). The GEM changes do mean you can
plug the existing allocator in the VIA driver into GEM directly. Whether
that would be a good idea or not given the other things you then need to
do I don't know - but it does seem to be me to be a stepping stone in the
right direction that is much easier to make ?

I'm fairly sure the real problem is that we have no way to treat stolen
pages as generic kernel memory. The ideal case would be to simply put
that memory back into the kernel memory pools. I did a little poking at
this but it makes suspend/resume horribly exciting and while some
hardware puts it at civilised bus addresses (end of 'real' memory
usually) not everyone seems to do it that way.

You can migrate the physical pages under a GEM object as well - in fact
it happens every time pages get swapped out and back in.

Re: KMS and TTM questions

[James Simmons]

> > 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 preloaded into
> the translation tables by the BIOS at vga init time.
> 
> It has fake VRAM type memory but thats really an illusion (although one
> the driver seems to like to keep up). The GEM changes do mean you can
> plug the existing allocator in the VIA driver into GEM directly. Whether
> that would be a good idea or not given the other things you then need to
> do I don't know - but it does seem to be me to be a stepping stone in the
> right direction that is much easier to make ?

That is correct. In fact the via driver detects what type of system ram is 
used so I can limit what resolutions are supported. Its possible that the 
memory doesn't have the bandwidth to support a very large resolution on 
older systems.

Re: KMS and TTM questions

[Alex Deucher]

On Tue, Oct 4, 2011 at 9:42 AM, James Simmons <jsimmons@infradead.org> 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 effectively in the GART with the 'stolen' pages preloaded into
>> the translation tables by the BIOS at vga init time.
>>
>> It has fake VRAM type memory but thats really an illusion (although one
>> the driver seems to like to keep up). The GEM changes do mean you can
>> plug the existing allocator in the VIA driver into GEM directly. Whether
>> that would be a good idea or not given the other things you then need to
>> do I don't know - but it does seem to be me to be a stepping stone in the
>> right direction that is much easier to make ?
>
> That is correct. In fact the via driver detects what type of system ram is
> used so I can limit what resolutions are supported. Its possible that the
> memory doesn't have the bandwidth to support a very large resolution on
> older systems.

Is vram actually handled via a scatter/gather page table or is it just
a pointer to a contiguous chunk of stolen system memory at the top of
ram?

Alex

Re: KMS and TTM questions

[James Simmons]

> >> > 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 preloaded into
> >> the translation tables by the BIOS at vga init time.
> >>
> >> It has fake VRAM type memory but thats really an illusion (although one
> >> the driver seems to like to keep up). The GEM changes do mean you can
> >> plug the existing allocator in the VIA driver into GEM directly. Whether
> >> that would be a good idea or not given the other things you then need to
> >> do I don't know - but it does seem to be me to be a stepping stone in the
> >> right direction that is much easier to make ?
> >
> > That is correct. In fact the via driver detects what type of system ram is
> > used so I can limit what resolutions are supported. Its possible that the
> > memory doesn't have the bandwidth to support a very large resolution on
> > older systems.
> 
> Is vram actually handled via a scatter/gather page table or is it just
> a pointer to a contiguous chunk of stolen system memory at the top of
> ram?

Stolen chuck. At the same time newer chipsets, VX900, have pcie gart 
table to move data to and from the "vram". 

Re: KMS and TTM questions

[Thomas Hellstrom]

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 effectively in the GART with the 'stolen' pages preloaded into
> the translation tables by the BIOS at vga init time.
>    

VRAM memory (at least on the older unichromes) is taken from on-board 
RAM and set up by the BIOS, and from a device programmer's point of view 
works like a discrete card VRAM, and is *not* part of the GART.

On some devices (K8M800) , the VRAM pages could be accessed by the CPU 
directly at the top of VRAM, which was substantially faster.

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 serve as a good starting point though, if I can remember where 
I put it....

/Thomas

Re: KMS and TTM questions

[James Simmons]

> 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 serve as a good starting point though, if I can remember where I put
> it....

I have a copy of your work already and yes I had to foward port it since 
the TTM api changed quite a bit from when you wrote that code.

Re: KMS and TTM questions

[James Simmons]

> On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> 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 used GEM and a simple allocator. The private allocator GEM change
> > means you can now use GEM to magic up objects that are in on card or
> > stolen memory where applicable not just backed in system memory.

I did both as I like my cake and to eat it too :-)

> 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
> should also state the limitations your advice leads to.

The accelerated moves is what made me implement an TTM layer. I 
wanted to try out using ttm_bo_move for the fbcon copyarea and 
imageblit functions as a experiment. Also in the future I like
totry out tiling support for fbcon with my dri driver. Yes fbcon 
supports tiles. All thats down the road. For now I just need to get a 
working driver.

Re: KMS and TTM questions

[James Simmons]

> > 	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 you've not already done os.

No special libkms for our hardware. Currently the via driver implements 
dumb buffers so I can work with the generic libkms library. Once tile 
support is implemented then a special buffer manager will need to be 
implemented.

Re: KMS and TTM questions

[Thomas Hellstrom]

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 used GEM and a simple allocator. The private allocator GEM change
> means you can now use GEM to magic up objects that are in on card or
> stolen memory where applicable not just backed in system memory.
>    

IMHO people making that comment just don't understand the problems TTM 
is trying to solve, but it usually dawns on them when they have worked 
on their own specialized solution for a year or so...

/Thomas

Re: KMS and TTM questions

[Alex Deucher]

On Mon, Oct 3, 2011 at 3:01 PM, James Simmons <jsimmons@infradead.org> 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 was not the front buffer from the video vram but a
> virtual queue buffer of about 256K in size. The second allocation was
> 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?
>        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 are supported.  That's a client driver (ddx, etc.)
implementation detail.  The cursor interface just basically has on,
off, and position. The client driver (ddx, etc.) can choose to upload
a ARGB or mono image.  We should probably add some sort of flag to KMS
to ask the driver what types of cursors they support so this could be
supported in a generic way.

Alex

Re: KMS and TTM questions

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 833 bytes --]


> >        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 are supported.  That's a client driver (ddx, etc.)
> implementation detail.  The cursor interface just basically has on,
> off, and position. The client driver (ddx, etc.) can choose to upload
> a ARGB or mono image.  We should probably add some sort of flag to KMS
> to ask the driver what types of cursors they support so this could be
> supported in a generic way.

That is the bit missing. I seen recently you had a patch for passing info 
to userland. It would be nice to add what color depths the cursor 
supports.

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS and TTM questions

[Alex Deucher]

On Tue, Oct 4, 2011 at 9:45 AM, James Simmons <jsimmons@infradead.org> 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 KMS cursor API doesn't really care what type of
>> cursors are supported.  That's a client driver (ddx, etc.)
>> implementation detail.  The cursor interface just basically has on,
>> off, and position. The client driver (ddx, etc.) can choose to upload
>> a ARGB or mono image.  We should probably add some sort of flag to KMS
>> to ask the driver what types of cursors they support so this could be
>> supported in a generic way.
>
> That is the bit missing. I seen recently you had a patch for passing info
> to userland. It would be nice to add what color depths the cursor
> supports.

I think Dave proposed something like that for the generic KMS ddx.

Alex