Just to let you know that the first step, file shuffling, is finished.
The rest will take more time but changes are less pervasive. Once you
update any private branches to the new directory layout, you should be
able to keep working as usual.
Here's a quick summary of the changes you might need
http://bugs.freedesktop.org/show_bug.cgi?id=14507
Michael Fu [EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
---
http://bugs.freedesktop.org/show_bug.cgi?id=14510
Summary: DRI2 fails to unmap buffer
Product: DRI
Version: DRI CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
OK, I found I had to merge rather than rebase in order to get my changes
into the new organization -- apologies for the bubble in the history.
Keith
José Fonseca wrote:
Just to let you know that the first step, file shuffling, is finished.
The rest will take more time but changes are less
I think it is almost impossible to rebase under these circumstances.
BTW, there was an unforeseen problem -- aux appears to be special
file on windows. Hence I had to rename that directory to
auxiliary...
Jose
On 2/15/08, Keith Whitwell [EMAIL PROTECTED] wrote:
OK, I found I had to merge
http://bugs.freedesktop.org/show_bug.cgi?id=14510
--- Comment #1 from Kristian Høgsberg [EMAIL PROTECTED] 2008-02-15 06:00:27
PST ---
Could you:
- attach the log
- try running the X server under gdb, set a break point on abort and the
attach the backtrace when the assertion fails
Are
Hello,
Last night I committed the DRI2 work that I've been sitting on for
quite a while now. This first code drop comes with a number of
caveats, though:
- only intel hardware, limited testing on i965 and up. Gotta
reinstall that box...
- everything committed on master, except the
On Fri, Feb 15, 2008 at 1:58 PM, Carl Worth [EMAIL PROTECTED] wrote:
On Fri, 15 Feb 2008 09:57:32 -0500, =?UTF-8?Q?Kristian_H=C3=B8gsberg?=
wrote:
Last night I committed the DRI2 work that I've been sitting on for
quite a while now.
Congratulations!
- only intel hardware, limited
http://bugs.freedesktop.org/show_bug.cgi?id=13918
--- Comment #1 from Eric Anholt [EMAIL PROTECTED] 2008-02-15 11:08:31 PST ---
So it must have failed with an error about the fence wait printed out Did the
X server die soon after (other rendering failed due to chip hang?) I can't
reproduce
http://bugs.freedesktop.org/show_bug.cgi?id=13918
--- Comment #2 from Thomas Hellström [EMAIL PROTECTED] 2008-02-15 12:13:02
PST ---
Actually it's entirely possible to fill the ring with rendering commands that
will take more than 3 seconds to complete. I see that problem with gltestperf
http://bugs.freedesktop.org/show_bug.cgi?id=13915
Eric Anholt [EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://bugs.freedesktop.org/show_bug.cgi?id=13918
--- Comment #3 from Thomas Hellström [EMAIL PROTECTED] 2008-02-15 14:07:02
PST ---
(In reply to comment #2)
It's hard to come up with a good way to solve this problem, but ideally we
shouldn't rely on fences to detect timeouts.
err...
http://bugs.freedesktop.org/show_bug.cgi?id=13918
--- Comment #4 from Eric Anholt [EMAIL PROTECTED] 2008-02-15 14:21:12 PST ---
Yeah, this has always been a problem, but things seem to have become more
fragile since TTM. We should fix the fence wait code to do basically what we
used to with
13 matches
Mail list logo
