On Tue, 2007-11-27 at 07:17 +0800, 郭超洪 wrote:
>
> /* TODO: Fix this more elegantly.
> * Sometimes (especially with multiple DRI clients), this code
> * runs immediately after a DRI client issues a rendering command.
> *
> * The accel code regularly inserts WAIT_UNTIL_IDLE
http://bugs.freedesktop.org/show_bug.cgi?id=13091
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|[TTM] glean abort with |glean abort with
|"
On Mon, 2007-11-26 at 17:15 -0500, Kristian Høgsberg wrote:
> > -full state
I assume you'll deal with hardware which supports multiple contexts and
avoid the need to include full state with each buffer?
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
http://bugs.freedesktop.org/show_bug.cgi?id=13091
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
Status|
http://bugs.freedesktop.org/show_bug.cgi?id=12570
Bug 12570 depends on bug 13091, which changed state.
Bug 13091 Summary: [TTM] glean abort with "Segmentation fault" in
GarbageCollectDRIDrawables
http://bugs.freedesktop.org/show_bug.cgi?id=13091
What|Old Value
hi, folks,
In radeon_dri.c, there is a routine RADEONEnterServer(). I can't understand
the
comment for the workaround at the end of this routine. Could you please help me
and if possible?
According to the comments, when R300 gets locked because some accel code fails
to set the 3D cache flus
Kristian Høgsberg wrote:
> On Nov 26, 2007 3:40 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote:
>> Kristian Høgsberg wrote:
>>> On Nov 22, 2007 5:37 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote:
>>> ...
I will go this way too for r300/r400/r500 there is not so much registers
change with diffe
On Nov 26, 2007 3:40 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> Kristian Høgsberg wrote:
> > On Nov 22, 2007 5:37 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> > ...
> >> I will go this way too for r300/r400/r500 there is not so much registers
> >> change with different contexts and registers
http://bugs.freedesktop.org/show_bug.cgi?id=13181
--- Comment #10 from [EMAIL PROTECTED] 2007-11-26 13:16 PST ---
I downgraded from GIT to 7.0.2 and the problem doesn't occur anymore. Going to
stay with 7.0.2 until the next stable release.
--
Configure bugmail: http://bugs.freedesk
Kristian Høgsberg wrote:
> On Nov 22, 2007 5:37 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> ...
>> I will go this way too for r300/r400/r500 there is not so much registers
>> change with different contexts and registers which need special treatment
>> will be handled by the drm (this boils down
http://bugs.freedesktop.org/show_bug.cgi?id=13391
--- Comment #3 from [EMAIL PROTECTED] 2007-11-26 11:40 PST ---
I've been compiling Mesa with -ggdb -g3 -O1. Can anyone see any reason why my
stack traces don't have line numbers?
--
Configure bugmail: http://bugs.freedesktop.org/use
http://bugs.freedesktop.org/show_bug.cgi?id=13391
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #12728|application/octet-stream|text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=13391
--- Comment #2 from [EMAIL PROTECTED] 2007-11-26 11:37 PST ---
Created an attachment (id=12728)
--> (http://bugs.freedesktop.org/attachment.cgi?id=12728&action=view)
Another log datapoint for a crashed server
This was running Mesa a8
On Nov 22, 2007 4:03 AM, Thomas Hellström <[EMAIL PROTECTED]> wrote:
...
> There are probably various ways to do this, which is another argument
> for keeping super-ioctls device-specific.
> For i915-type hardware, Dave's approach above is probably the most
> attracting one.
> For Poulsbo, all stat
On Nov 22, 2007 5:37 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote:
...
> I will go this way too for r300/r400/r500 there is not so much registers
> change with different contexts and registers which need special treatment
> will be handled by the drm (this boils down to where 3d get rendered and
> w
Kristian Høgsberg wrote:
> On Nov 22, 2007 4:23 AM, Keith Whitwell <[EMAIL PROTECTED]> wrote:
> ...
>>> My guess for one way is to store a buffer object with the current state
>>> emission in it, and submit it with the superioctl maybe, and if we have
>>> lost context emit it before the batchbuffer
On Nov 22, 2007 4:23 AM, Keith Whitwell <[EMAIL PROTECTED]> wrote:
...
> > My guess for one way is to store a buffer object with the current state
> > emission in it, and submit it with the superioctl maybe, and if we have
> > lost context emit it before the batchbuffer..
>
> The way drivers actual
On Nov 22, 2007 12:19 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> Hi Kristian,
>
> Got a question on cliprect this might be dumb but what happen if hw is limited
> on numbers of cliprect it can handle ? Does the X server also provide some
> kind
> of informations like buffer draw order (in whic
18 matches
Mail list logo
