Here it is.
Looks okay to me.. check it in yourself..
Dave.
Maarten.
On 10/2/07, Maarten Maathuis [EMAIL PROTECTED] wrote:
You seem to be correct, i must have added the tmp variable in attempt
to solve something, that i ended up solving differently.
I will redo the patch and send
Hi,
On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote:
I wrote up the DRI2 design on a wiki page here:
http://wiki.x.org/wiki/DRI2
Is that a new DRI version intended to work with Gallium only ?
Xav
Kristian Høgsberg wrote:
Hi,
I wrote up the DRI2 design on a wiki page here:
http://wiki.x.org/wiki/DRI2
It's the result of the discussions we had during my redirected
rendering talk and several follow up discussions with Keith Whitwell
and Michel Daenzer. Relative to the design I
On Wed, 2007-10-03 at 14:08 -0700, Ian Romanick wrote:
diff --git a/linux-core/xgi_cmdlist.c b/linux-core/xgi_cmdlist.c
index 261f4e1..35f7e1b 100644
--- a/linux-core/xgi_cmdlist.c
+++ b/linux-core/xgi_cmdlist.c
@@ -45,7 +45,7 @@ static inline void dwWriteReg(struct drm
Keith Whitwell wrote:
Kristian Høgsberg wrote:
Hi,
I wrote up the DRI2 design on a wiki page here:
http://wiki.x.org/wiki/DRI2
It's the result of the discussions we had during my redirected
rendering talk and several follow up discussions with Keith Whitwell
and Michel Daenzer.
http://bugs.freedesktop.org/show_bug.cgi?id=8357
--- Comment #8 from [EMAIL PROTECTED] 2007-10-04 08:01 PST ---
I believe this 2560 limitation come from cliprect offset a 1440 and
according to ATI driver viewport should be able to reach 4096x4096 on
r300/r400, so this 1440 offset is
http://bugs.freedesktop.org/show_bug.cgi?id=11499
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment
On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote:
There is an issue with the design, though, related to how and when the
DRI driver discovers that the front buffer has changed (typically
resizing).
Why would the rendering application even need to know the size of the
front buffer?
On 10/4/07, Keith Packard [EMAIL PROTECTED] wrote:
On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote:
There is an issue with the design, though, related to how and when the
DRI driver discovers that the front buffer has changed (typically
resizing).
Why would the rendering
Keith Whitwell wrote:
Kristian Høgsberg wrote:
On 10/4/07, Keith Packard [EMAIL PROTECTED] wrote:
On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote:
There is an issue with the design, though, related to how and when the
DRI driver discovers that the front buffer has changed
Kristian Høgsberg wrote:
On 10/4/07, Keith Packard [EMAIL PROTECTED] wrote:
On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote:
There is an issue with the design, though, related to how and when the
DRI driver discovers that the front buffer has changed (typically
resizing).
Why
http://bugs.freedesktop.org/show_bug.cgi?id=12385
--- Comment #5 from [EMAIL PROTECTED] 2007-10-04 11:49 PST ---
(In reply to comment #4)
Created an attachment (id=11836)
-- (http://bugs.freedesktop.org/attachment.cgi?id=11836action=view) [details]
xf86-video-intel patch
Do
http://bugs.freedesktop.org/show_bug.cgi?id=11499
--- Comment #9 from [EMAIL PROTECTED] 2007-10-04 11:59 PST ---
(In reply to comment #8)
The fragment programs used for color space conversion from planar YUV to RGB
by
mplayer with the methods 2, 3 and 4 are using TEX instructions
Okay this is my first public efforts at the i915 driver superioctl.
Please review and give out about anything I missed, I'm sure the error
handling needs some work. But I thought I'd get it out there..
I have a Mesa side to this in my personal mesa tree (i915-superioctl
branch) but I just
14 matches
Mail list logo
