David Bronaugh wrote:
Tomas Carnecky wrote:
David Bronaugh wrote:
Another option would be to design a generic, more low-level wrapper
for graphics hardware. In my opinion this is a huge undertaking (ever
read chip docs? You try integrating 3000 pages of information (that
would be around 5
--- Tomas Carnecky [EMAIL PROTECTED] wrote:
David Bronaugh wrote:
Tomas Carnecky wrote:
David Bronaugh wrote:
Another option would be to design a generic, more low-level wrapper
for graphics hardware. In my opinion this is a huge undertaking
(ever
read chip docs? You try
I see this thread is also on your dri-devel list.
http://sourceforge.net/mailarchive/forum.php?thread_id=4573552forum_id=7177
I responded in April, but not on this list. So I am replying again here.
-- Forwarded message --
Date: Mon, 26 Apr 2004 23:43:42 -0700 (PDT)
From: Jeremy
Am Montag, 26. April 2004 14:18 schrieb Dieter Nützel:
Am Donnerstag, 5. Februar 2004 19:38 schrieb Dieter Nützel:
Have you seen, that it is much faster (hardware accelerate?) in the
broken area (on the right and right/below corner)?
No progress.
Any ideas how to disable some features in
Mike Mestnik wrote:
I think every thing Tomas Carnecky has said here about device driver
design is valid and dose apply to the DRM/dri. He may not know every
thing about system security, but we also all have our strangths and his
strangth is oviously device design. One way of interpeting what
On Thu, 2004-05-27 at 11:27, Tomas Carnecky wrote:
Each slash in 'Mesa/DRI/DRM' stands for an interface, which is more or
less predefined (for example drm_*.h in drivers/char/drm).
No, it's not. Ian pointed that out, so why bring it up again?
--
Earthling Michel Dnzer | Debian
On Thu, 2004-05-27 at 12:04, Tomas Carnecky wrote:
I just don't think there should be one interface for all devices, as it
is now with DRM.
No, there isn't. There just happen to be some things common to all
drivers.
The userspace dri driver is the only user of these kernel drivers.
No,
The idea is to reduce the kernel mod to nothing more then device
enumeration and detection.
However you solve it.. I don't care about how the kernel driver --
userspace driver interface is defined or implemented. I just don't think
there should be one interface for all devices, as it is
Michel Dnzer wrote:
The userspace dri driver is the only user of these kernel drivers.
No, there's also the DDX drivers, XvMC, ... and there could be more in
the future.
So you tell me that there are at least three (DRI/DDX/XvMC) libraries
which do basically the same thing?
If, and that's what
On Tue, 2004-05-25 at 21:55, Nicolai Haehnle wrote:
As you may be aware, I was trying to get R300 support into a state where it
is possible to start OpenGL applications, let them hang the CP and *not*
bring down the entire machine.
Looks like I was successful :)
Nice!
The attached
Attached is the patch I made to make more cliprects when 2048. It
dosen't have any code to move the 3d-viewport, I'm still looking into how
that will work.
Where can I find docs on debuging the client GL driver? Just using ddd
didn't work and gave me a broken bt.
On Thu, 2004-05-27 at 14:14, Tomas Carnecky wrote:
Michel Dnzer wrote:
The userspace dri driver is the only user of these kernel drivers.
No, there's also the DDX drivers, XvMC, ... and there could be more in
the future.
So you tell me that there are at least three
On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset.
It's hard for me to recognize anything; can you describe your
observations?
I still have to find where rmesa-state.color.drawOffset comes from and
what effect the
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset.
It's hard for me to recognize anything; can you describe your
observations?
The data was shifted to the right,
# On 26-May-2004, [EMAIL PROTECTED] wrote:
# Me and my friend run glxgears with 1024x768 and 16bpp.
# Patrick, I compiled dri cvs, so it doesn't matter what version of xfree 4.3
# 4.4 etc I have. And dri was enabled, as you could see from attached file.
#
# Okay, that gets us somewhere. DRI
On Thu, 2004-05-27 at 15:00, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset.
It's hard for me to recognize anything; can you describe your
Tomas Carnecky wrote:
Each slash in 'Mesa/DRI/DRM' stands for an interface, which is more or
less predefined (for example drm_*.h in drivers/char/drm).
Why not 'OpenGL/Hardware'?
Oh for cryin' out loud. Have you read ANYTHING about how the DRI
architecture works, or are you just here to divert
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
copies. Since dri_util.[ch] are only used by the drivers, I'm going to
move them
--- Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
copies. Since dri_util.[ch] are
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
copies. Since
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
copies. Since
Keith Whitwell wrote:
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the
DRI
Keith Whitwell wrote:
Which reminds me; we will need to get an uptodate Mesa into extras/Mesa
and go back to periodically updating it...
I was thinking that right after we get all this stuff taken care of
would be a perfect time. :)
---
This
There is another copy:
xc/lib/XvMC/hw/i810/xf86drm.c
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Thu, 2004-05-27 at 15:00, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset.
It's hard for
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to try and wrap up the remaining issues preventing a
single
driver binary. As part of that, I'm going to move the Mesa copies
of
dri_util.[ch] and glcontextmodes.[ch].
Alex Deucher wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to try and wrap up the remaining issues preventing a
single
driver binary. As part of that, I'm going to move the Mesa copies
of
dri_util.[ch] and
Alex Deucher wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
As the xc/ tree will continue having to import Mesa to extras/Mesa,
the libGL
code could pick it up from there.
could that be avoided with a SW only DRI driver like we've discussed
several times on IRC and the ML? if libGLcore goes
Around 20 o'clock on May 27, Keith Whitwell wrote:
If the X server starts dynamically loading XYZ_dri.so and falling back to
software_dri.so if that fails, you mean?
That would be great; no GL bits inside the X server
In that case, I guess X no longer needs an extras/Mesa, though they may
Around 12 o'clock on May 27, Ian Romanick wrote:
I'm pretty sure that XFree86 and Xorg will continue to want to build 3D
drivers as part of their distribution process. Even so, there are parts
of Mesa that are needed to build libGL.so and libglx.a.
With stable interfaces and published
I'm using Redhat xorg-x11-6.7.0-2
The addresses coming back from these get_proc_address calls don't look quit
right. When one is used in context-gl.get_program_iv_arb() it segfaults. I'm
using an R128 which does not have hardware shaders.
Should these calls be returning values as if they were
Keith Packard wrote:
Around 12 o'clock on May 27, Ian Romanick wrote:
I'm pretty sure that XFree86 and Xorg will continue to want to build 3D
drivers as part of their distribution process. Even so, there are parts
of Mesa that are needed to build libGL.so and libglx.a.
With stable interfaces
Jon Smirl wrote:
I'm using Redhat xorg-x11-6.7.0-2
The addresses coming back from these get_proc_address calls don't look quit
right. When one is used in context-gl.get_program_iv_arb() it segfaults. I'm
using an R128 which does not have hardware shaders.
Should these calls be returning values as
Stephane Marchesin wrote:
Jon Smirl wrote:
I'm using Redhat xorg-x11-6.7.0-2
The addresses coming back from these get_proc_address calls don't look
quit
right. When one is used in context-gl.get_program_iv_arb() it
segfaults. I'm
using an R128 which does not have hardware shaders.
Should these
The final file shuffling step will be to make the DRI tree and the Mesa tree
use the libdrm.a build in the drm module. Right now we have *3* copies of the
same code. There is a copy in each of: drm/libdrm, xc/xc/lib/GL/dri/drm, and
src/mesa/drivers/dri/dri_client. That's just nuts (but I
On Thu, May 27, 2004 at 05:55:29PM -0700, Jon Smirl wrote:
| Why do you dynamically generate a dispatch for unknown functions instead of
| just returning null? ...
Since I'm one of the people who proposed that behavior, I guess I should
save Ian the trouble of explaining. :-)
There are several
should I be able to using FC2, set LIBGL_DRIVERS_PATH to my Mesa built
drivers and have it work, or is that interface not one that stays stable?
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -150064480 (LWP 4593)]
0x007f189e in memset () from /lib/tls/libc.so.6
(gdb)
I was getting weird segfaults like that too. I'm using xorg-x11-6.7.0-2.i386.rpm
with FC2. The problem seems to be in the upgrade process, upgrading from
xorg-x11-6.7.0-0.5.i386.rpm to -2 did not delete somethings that needed to be
deleted (like the tls dirs). I whacked my X11R6 directories and
38 matches
Mail list logo
