On Tue, Sep 01, 2009 at 10:01:24PM -0700, Corbin Simpson wrote:
Then have an Intel-specific bit of code. Do a batchbuffer
checker/relocator/munger; we've got one for Radeons, and I'm sure you
guys need to do something similar for relocating BOs.
That's actually what I originally wanted to do.
Daniel Vetter skrev:
On Mon, Aug 31, 2009 at 02:58:15PM +0200, Thomas Hellström wrote:
...
Is this some new (embedded) hw support your working on (that supports
gallium), Thomas? Or why do you think gallium needs overlay support?
I must stress this is not Gallium.
On Wed, 2009-09-02 at 08:24 +0200, Daniel Vetter wrote:
btw: intel hw has some nice support for executing untrusted batchbuffers,
so no monsterous checker/relocater/munger already present.
The radeon CS checker goes far beyond what the Intel hardware provides
(and can provide, as e.g. it
2009/9/2 Michel Dänzer mic...@daenzer.net:
On Wed, 2009-09-02 at 08:24 +0200, Daniel Vetter wrote:
btw: intel hw has some nice support for executing untrusted batchbuffers,
so no monsterous checker/relocater/munger already present.
The radeon CS checker goes far beyond what the Intel
That said, the suggestion to use command streams for the overlay doesn't
make much sense to me. If that was a good idea, why aren't we doing
modesetting that way?
Modesetting on nvidia g80+ is done through a command stream, so it
isn't an entirely crazy idea.
Maarten.
Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO this has two solutions:
a) complicated to communicate the constrains to userspace. This is either
to generic
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote:
Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO this has two solutions:
a) complicated to
2009/9/1 Keith Whitwell kei...@vmware.com:
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote:
Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO this
On Tue, Sep 01, 2009 at 12:10:20PM +0200, Stephane Marchesin wrote:
As I said, if my hw overlay only does YUY2 and I want to expose
YV12/I420 (because that's what everyone wants), I get to do the
conversion myself. Now in the old case I could do it in the driver,
but now you can either:
-
Stephane Marchesin skrev:
2009/9/1 Keith Whitwell kei...@vmware.com:
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote:
Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the
2009/9/1 Thomas Hellström tho...@shipmail.org:
Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO this has two solutions:
a) complicated to communicate the
On Tue, Sep 01, 2009 at 10:56:18AM -0400, Alex Deucher wrote:
I'm failing to see why we need an overlay ioctl at all. You end up
pulling a relatively large amount of state setup into the drm. Why
not treat the overlay like EXA or textured video or 3D? The overlay
regs are pipelined on most
On Mon, Aug 31, 2009 at 02:58:15PM +0200, Thomas Hellström wrote:
...
Is this some new (embedded) hw support your working on (that supports
gallium), Thomas? Or why do you think gallium needs overlay support?
I must stress this is not Gallium. It's the Xorg state-tracker that uses
Gallium
On 09/01/2009 02:06 PM, Daniel Vetter wrote:
On Tue, Sep 01, 2009 at 10:56:18AM -0400, Alex Deucher wrote:
I'm failing to see why we need an overlay ioctl at all. You end up
pulling a relatively large amount of state setup into the drm. Why
not treat the overlay like EXA or textured video or
Open issues:
- Flickering. But when the frame is not changed, this stabilizes
after a few seconds (at most). This is in a 855GM and a 865G, other
chipset variants are untested.
- Runs in sync with the gpu, i.e. unnecessary waiting. Unfortunately
changes in this area tend to hang the hw, so
Daniel Vetter wrote:
Open issues:
- Flickering. But when the frame is not changed, this stabilizes
after a few seconds (at most). This is in a 855GM and a 865G, other
chipset variants are untested.
- Runs in sync with the gpu, i.e. unnecessary waiting. Unfortunately
changes in this
Hi Thomas,
On Mon, Aug 31, 2009 at 11:34:00AM +0200, Thomas Hellström wrote:
Hi,
Is there any way we can try and put together a generic drm interface for
this instead of an Intel-specific one?
I've tried to make the ioctl somewhat generic. That's the reason for the
generic buffer format flags
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
someone implements overlay support for another chipset. But I don't really
count on that, because at least radeon has textured
On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
2009/8/31 Thomas Hellström tho...@shipmail.org:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
someone implements overlay support for another chipset. But I don't really
On Mon, Aug 31, 2009 at 01:57:55PM +0200, Thomas Hellström wrote:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
someone implements overlay support for another chipset.
Daniel Vetter wrote:
On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO this has two solutions:
a) complicated to communicate the constrains to userspace. This is either
to generic or not suitable for everything.
23 matches
Mail list logo
