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.
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
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.
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.
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
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.
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.
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
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.
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.
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.
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
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".
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
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.
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.
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.
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
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
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.
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
dri-devel@lists.freedesktop.org
-
Alan Cox -
Alex Deucher -
Dave Airlie -
James Simmons -
Jerome Glisse -
Thomas Hellstrom