> 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.
-
2009/9/2 Michel Dänzer :
> 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
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 d
On Wed, Sep 02, 2009 at 10:18:36AM +0200, Thomas Hellström wrote:
> > ...
> >Nope, Xv has one fixed format with stride == line length.
>
> This is perhaps a little out of scope, but I'm pretty sure Xv sets
> up the HW needed stride of Xv images and pushes that to the client,
> and if the client d
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
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
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 vi
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 mo
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
>
2009/9/1 Thomas Hellström :
> Stephane Marchesin wrote:
>> 2009/8/31 Thomas Hellström :
>>
>>
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
Stephane Marchesin skrev:
> 2009/9/1 Keith Whitwell :
>
>> On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote:
>>
>>> Stephane Marchesin wrote:
>>>
2009/8/31 Thomas Hellström :
>> The problem I see with Xv-API-in-kernel is that of the various h
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:
> -
2009/9/1 Keith Whitwell :
> On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote:
>> Stephane Marchesin wrote:
>> > 2009/8/31 Thomas Hellström :
>> >
>> >
>> >>> The problem I see with Xv-API-in-kernel is that of the various hw
>> >>> constrains on the buffer layout. IMHO this has two solution
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote:
> Stephane Marchesin wrote:
> > 2009/8/31 Thomas Hellström :
> >
> >
> >>> 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 t
Stephane Marchesin wrote:
> 2009/8/31 Thomas Hellström :
>
>
>>> 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
2009/8/31 Thomas Hellström :
>> 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.
>>
>
> II
Daniel Vetter wrote:
> On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote:
>
>> 2009/8/31 Thomas Hellström :
>>
>>> Daniel Vetter wrote:
>>>
>>> ...
>>>
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the k
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
2009/8/31 Thomas Hellström :
> 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 t
On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote:
> 2009/8/31 Thomas Hellström :
> > 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
> >> someon
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 textu
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 fl
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 thi
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 le
24 matches
Mail list logo
