Hi forward this message to dri-devel Mailing List, where you could find
more tester on i815 DRI drives .
I hope I don't had made a loop :)
Forwarded Message
From: Andreas Mohr <[EMAIL PROTECTED]>
To: Pavel Machek <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>, [EMAIL
In playing around yesterday, we found that some drivers will
unnecessarily enable interrupts for vblank events. Since these tend to
happen frequently (60+ Hz), they'll cause your CPU to wake up a lot,
which will waste power if they're not really in use.
This patch hacks the radeon driver to on
http://bugzilla.kernel.org/show_bug.cgi?id=8427
Summary: Kernel Panic on shuting down with Xserver using i810
driver
Kernel Version: 2.6.18-4-amd64
Status: NEW
Severity: normal
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL
On Fri, 2007-05-04 at 16:57 +0100, Keith Whitwell wrote:
> That's a special case of a the general problem of what do you do when a
> client submits any validation list that can't be satisfied. Failing to
> render isn't really an option, either the client or the memory manager
> has to either p
Keith Packard wrote:
>> OTOH, letting DRM resolve the deadlock by unmapping and remapping shared
>> buffers in the correct order might not be the best one either. It will
>> certainly mean some CPU overhead and what if we have to do the same with
>> buffer validation? (Yes for some operations w
On Fri, 2007-05-04 at 14:32 +0200, Thomas Hellström wrote:
> If there isn't we can at least consider other
> alternatives that resolve the deadlock issue but that also will help
> clients synchronize and keep data coherent.
If clients want coherence, they're welcome to implement their own
locki
On Fri, 2007-05-04 at 11:40 +0200, Jerome Glisse wrote:
> On a side note i think this scheme also fit well with gpu having
> several context and which doesn't need big validation (read
> nv gpu).
Yeah, I want to make sure we have a simple model that supports
multi-context hardware while also avoi
http://bugs.freedesktop.org/show_bug.cgi?id=6664
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment #
On Fri, 2007-05-04 at 10:07 +0200, Thomas Hellström wrote:
>
> It's rare to have two clients access the same buffer at the same time.
> In what situation will this occur?
Right, what I'm trying to avoid is having any contention for
applications *not* sharing the same objects.
If there is any
On 5/4/07, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> There was a typo in my mail, i meaned lock not lockup
> when i was talking about apps sending data to gpu.
> And if multiple instance of glxgears are successfull
> to make the gpulockup this is because you are then
> sending megs of vertex to th
http://bugs.freedesktop.org/show_bug.cgi?id=10855
Summary: on Intel 945G, (beryl or compiz) + glxgears =
DRM_I830_CMDBUFFER: -22
Product: Mesa
Version: 6.5
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> I was actually referring to an example where two clients need to have a
> buffer mapped and access it at exactly the same time.
> If there is such a situation, we have no other choice than to drop the
> buffer locking on map. If there isn't w
Jerome Glisse wrote:
> On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>> Jerome Glisse wrote:
>> > On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>> >> Keith Packard wrote:
>> >> > On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
>> >> >
>> >> >
>> >> >> It might be possib
On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Jerome Glisse wrote:
> > On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> >> Keith Packard wrote:
> >> > On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
> >> >
> >> >
> >> >> It might be possible to find schemes that work a
Jerome Glisse wrote:
> On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>> Keith Packard wrote:
>> > On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
>> >
>> >
>> >> It might be possible to find schemes that work around this. One way
>> >> could possibly be to have a buffer mapping
On 5/4/07, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> > Keith Packard wrote:
> > > On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
> > >
> > >
> > >> It might be possible to find schemes that work around this. One way
> > >> could
On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Keith Packard wrote:
> > On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
> >
> >
> >> It might be possible to find schemes that work around this. One way
> >> could possibly be to have a buffer mapping -and validate order for
> >>
On 5/4/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> Jerome Glisse írta:
> > On 5/4/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> >
> >> Oliver McFadden írta:
> >>
> >>> On 5/3/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> Hi,
>
> sorry for the crosspost
Keith Packard wrote:
> On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
>
>
>> It might be possible to find schemes that work around this. One way
>> could possibly be to have a buffer mapping -and validate order for
>> shared buffers.
>>
>
> If mapping never blocks on anything
Jerome Glisse írta:
> On 5/4/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
>
>> Oliver McFadden írta:
>>
>>> On 5/3/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
>>>
>>>
Hi,
sorry for the crossposting, I don't know who to address.
I am experimenting t
On 5/4/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> Oliver McFadden írta:
> > On 5/3/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> >
> >> Hi,
> >>
> >> sorry for the crossposting, I don't know who to address.
> >>
> >> I am experimenting the new CFS scheduler on Linux
> >> and tried to
Oliver McFadden írta:
> On 5/3/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> sorry for the crossposting, I don't know who to address.
>>
>> I am experimenting the new CFS scheduler on Linux
>> and tried to start multiple glxgears to see whether
>> they are really running smoot
22 matches
Mail list logo
