Do you have this fix?
= linux/drm_scatter.h 1.6 vs edited =
--- 1.6/linux/drm_scatter.h Sun Sep 5 21:22:06 2004
+++ edited/linux/drm_scatter.h Thu Sep 16 01:11:13 2004
@@ -73,7 +73,7 @@
DRM_DEBUG( %s\n, __FUNCTION__ );
- if (drm_core_check_feature(dev, DRIVER_SG))
+
Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying save the state at the next unlock, which means
memcpying the state atoms off. When we actually see the context get
lost,
All GL application are displayed at the end on a Window. this window are
traditional X Server window, which could be clipped, moved, etc.
I would like to add support to redirect the image, which should be
displayed at the end of rendering in a window to an off-screen or a
pixmap. I want to add
Amir Bukhari wrote:
All GL application are displayed at the end on a Window. this window are
traditional X Server window, which could be clipped, moved, etc.
I would like to add support to redirect the image, which should be
displayed at the end of rendering in a window to an off-screen or a
Okay I've just gotten rid of the __HAVE_COUNTER* macros, drivers can now
just add their counters in their driver_register_fns routines...
The only major macro left are the ioctls, I have an inkling of a plan on
how to get rid of them..
Dave.
--
David Airlie, Software Engineer
On Mon, 2004-09-20 at 14:07, Keith Whitwell wrote:
Amir Bukhari wrote:
On Mon, 2004-09-20 at 13:24, Keith Whitwell wrote:
Amir Bukhari wrote:
All GL application are displayed at the end on a Window. this window are
traditional X Server window, which could be clipped, moved, etc.
I
Amir Bukhari wrote:
On Mon, 2004-09-20 at 14:07, Keith Whitwell wrote:
Amir Bukhari wrote:
On Mon, 2004-09-20 at 13:24, Keith Whitwell wrote:
Amir Bukhari wrote:
All GL application are displayed at the end on a Window. this window are
traditional X Server window, which could be clipped, moved,
As a heads up, in this commit,
revision 1.116
date: 2004-09-05 10:54:58 +; author: airlied; state: Exp; lines: +9 -9
merge back bunch of whitespace and misc changes from kernel
drmP.h was changed to include linux/cdev.h, which
On Sul, 2004-09-19 at 21:40, Keith Packard wrote:
I just need to know where the frame buffer lives; it can move or change
pitch at any time. I can even deal with the frame buffer moving without
warning if necessary. What I can't handle is off-screen memory suddenly
disappearing on me; I
On Monday 20 September 2004 05:57, Keith Whitwell wrote:
Jon Smirl wrote:
I just checked a small change into DRM CVS that adds sysfs i2c support
to the linux radeon driver. The patch includes some GPL licensed code
extracted from the Linux kernel. The GPL files are only in the
drm/linux
On Monday 20 September 2004 12:08, Jon Smirl wrote:
No GPL code doesn't make sense for the Linux drivers. The only place
Linux drivers can be used is in a GPL environment. For example there
is a 600 line sysfs support skeleton file I want to include. This file
is intended to be brought into a
Hi Jon!
Monday 20, at 02:15:26 AM you wrote:
Do you have this fix?
skip
Yes, I have the 20040919 snapshot and drm from cvs, so this patch is
applyed here.
--
WBR, Konstantin chat with ==ICQ: 109916175
Lepikhov,speak to ==JID: [EMAIL PROTECTED]
aka L.A. Kostis
On Mon, 20 Sep 2004 12:29:30 -0400, Adam Jackson [EMAIL PROTECTED] wrote:
License compatibility != OS compatibility, please don't conflate the two. X
runs on more than just Linux, and source is distributed as an aggregate. If
The Linux DRM driver does not run anywhere but on Linux. The GPL
Keith,
We haven't managed to write such a policy down yet, and demonstrate full
consensus of the community. So far, I'd describe the policy today as
first, do no harm.
It is certainly on the board's radar screen to try help the community
generate a policy with full feedback from the membership.
On Mon, 2004-09-20 at 18:47, Ian Romanick wrote:
Amir Bukhari wrote:
that is correct if the client use DRI, but what if the applications use
GLX extension like glxgeer. I think getting GLX is simpler than
getting DRI. for examlpe by catcing attaching GL to window and let GLX
assume this
This policy prevents code reuse from other parts of Linux. It is
counter productive to take working GPL code that is specific to Linux,
rewrite it for the MIT license, and then resubmit it to Linux under
the GPL again. The policy is fine for the cross platform code but it
doesn't make sense for
I think if you read it again more carefully, it doesn't say that.
Of course, it is a strawman I just put together, so I may not have
said what I meant
- Jim
On Mon, 2004-09-20 at 13:25, Jon Smirl wrote:
This policy prevents code reuse from other parts of Linux. It is
Also note the embedded issue raised during the Cairo relicencing
discussion, however. We have a lot of embedded X use both
historically and going forward; I know that hasn't occurred much
in the DRI part of the world, but it is commonplace for X itself,
and can be expected to be common in the
On Monday 20 September 2004 12:59, Jon Smirl wrote:
On Mon, 20 Sep 2004 12:29:30 -0400, Adam Jackson [EMAIL PROTECTED] wrote:
License compatibility != OS compatibility, please don't conflate the two.
X runs on more than just Linux, and source is distributed as an
aggregate. If
The Linux
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1428
Summary: drmAddMap failed with latest drm CVS
Product: DRI
On Monday 20 September 2004 13:17, Amir Bukhari wrote:
On Mon, 2004-09-20 at 18:47, Ian Romanick wrote:
I just want to clarify things. Do you want to write a new application
that renders to off-screen or do you want to redirect the output of an
arbitrary existing appliation to off-screen?
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1428
--- Additional Comments From [EMAIL PROTECTED] 2004-09-20 11:02 ---
I checked
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1428
--- Additional Comments From [EMAIL PROTECTED] 2004-09-20 11:07 ---
Yes, just
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
5:00PM EDT or 2:00PM PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous
Felix, I'm removing the size check from addmap with a permanent map.
I've now encountered X asking for maps both smaller and larger that
what the hardware allows. This is why we need to get this code out of
X an into the driver. I'll fix the code to map the legal value for the
hardware (from the
On Mon, 2004-09-20 at 19:47, Adam Jackson wrote:
On Monday 20 September 2004 13:17, Amir Bukhari wrote:
On Mon, 2004-09-20 at 18:47, Ian Romanick wrote:
I just want to clarify things. Do you want to write a new application
that renders to off-screen or do you want to redirect the output
Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying save the state at the next unlock, which means
memcpying the state atoms off.
Am Montag, 20. September 2004 21:52 schrieb Dieter Nützel:
Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying save the state
Eric Anholt wrote:
This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears. I didn't have
any interesting apps besides glxgears handy to benchmark with.
I should be able to give it a spin on viewperf sometime this week...
On Monday 20 September 2004 15:36, Amir Bukhari wrote:
On Mon, 2004-09-20 at 19:47, Adam Jackson wrote:
You still want pbuffers. Composite should enable the compmgr to redirect
GL contexts to pbuffers without the GL app knowing about it. This
requires more pbuffer support than currently
A pbuffer is the GL analog of an offscreen pixmap. The spec is at
http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt
Currently we have support for pbuffers in indirect contexts only, which are
contexts where the server does the rendering (in our case, in software).
Amir Bukhari wrote:
I will start on it from now on, but I have a small question. is indirect
rendering use 3D accelarator for 3D operation or it is all software?
for example glxgear use GLX, is that mean it use indirect rendering?
APP --- GLX (libglx) DRI --- Hardware. (indirect rendering)
On Mon, 2004-09-20 at 23:44, Ian Romanick wrote:
Amir Bukhari wrote:
I will start on it from now on, but I have a small question. is indirect
rendering use 3D accelarator for 3D operation or it is all software?
for example glxgear use GLX, is that mean it use indirect rendering?
Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying save the state at the next unlock, which means
memcpying the state atoms off. When we actually see the context get
lost,
Amir Bukhari wrote:
that mean all applications, which linked with libglx, will be only
software rendered at this moment, when DRI is used. I don't want to talk
when using GLX module from nvidia. Nvidia is outside our scope.
Applications don't link with libglx. libglx is a module loaded by the
On Monday 20 September 2004 17:54, Amir Bukhari wrote:
On Mon, 2004-09-20 at 23:44, Ian Romanick wrote:
Direct rendering:
APP - libGL - DRI driver (*_dri.so) - DRM (kernel module) - hardware
Indirect rendering:
APP - libGL - GLX protocol to X-server - ?
In the current
On Tue, 21 Sep 2004 00:10:31 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Llu, 2004-09-20 at 18:38, Adam Jackson wrote:
Inclusion is not conversion, in this case. All the copyright statements in
the DRM source (excluding your recent commit) specify BSD licenses. If the
bug-fixers wanted
On Tue, 21 Sep 2004 00:56:38 +0100, Sérgio Monteiro Basto
[EMAIL PROTECTED] wrote:
Hi
On Thu, 2004-09-16 at 14:17, Alex Deucher wrote:
regarding mergedfb, Sergio, what chip do you have?
86C387 TwisterK (8D02)
S3 Inc. VT8636A [ProSavage KN133] AGP4X VGA Controller (TwisterK)
AFAIK,
38 matches
Mail list logo
