On Mon, 2004-09-20 at 15:00, Roland Scheidegger wrote:
> 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
> >
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,
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 w
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 their changes to apply under the GPL they should have
> indicated that
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 -> ?
> >
> >
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
X-s
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
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 renderin
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)
>
> 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).
>
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 curre
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...
-
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
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
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
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 p
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 IR
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 n
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 i
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-sc
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 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
>
>
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 futu
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
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 the
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
> >
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, 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
Hi Jon!
Monday 20, at 02:15:26 AM you wrote:
> Do you have this fix?
>
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 write
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 just a pixmap not a window, thus it will render it to a
pi
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
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 driver and then edited. It is a
complete waste of time re
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
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;
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 , which unfortunately doesn
Dave Airlie wrote:
Okay I've just gotten rid of the __HAVE_COUNTER* macros, drivers can now
just add their counters in their driver_register_fns routines...
I don't know how useful the counters ever were - have you considered just
chopping them out altogether?
Keith
--
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, et
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, m
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
http://www.skynet
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
pixmap
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 thi
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
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 directory. No GPL code was added to drm/shared or drm/bsd so
the BSD
43 matches
Mail list logo
