I'm fully aware of the lack of documentation for recent graphics cards
and the problems associated with that. Maybe the open source vs closed
source problem is already a lost battle especially already. The
situation seems to be much better for other HW such as audio cards,
NICs, printers, etc
Svante Signell wrote:
However, my original question remain: Which card is usable with DRI open
source drivers for modern games? Also, is the S3TC issue resolved for
the cards I mentioned before: Mach64, G400, Banshee and Radeon 9000 PRO.
It's absolutely resolved for mach64, G400, and banshee: the
Ian Romanick wrote:
Ian Romanick wrote:
The one caveat with this patch is the x86 SSE codegen is disabled
for all TexCoord and MultiTexCoord commands. If you look at the
changes to r200_vtxfmt_c.c, you'll see that I had to make some changes
to the way those routines work.
The previous
why do I get the impression we are discussing kgi or at least the goals of
kgi? without mentioning it ..is kgi a bad word around these parts? :-)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
Jon Smirl writes:
I'm putting together a document for Kernel Summit that describes the issues
around graphics device drivers. The kernel developers are currently making first
pass comments on it. As soon as I fold their comments in I'll post it to
fb-dev, dri-dev and wherever else is
However, my original question remain: Which card is usable with DRI open
source drivers for modern games? Also, is the S3TC issue resolved for
the cards I mentioned before: Mach64, G400, Banshee and Radeon 9000 PRO.
Since I'm replying to your mail Vladimir, how about the TV-out issue
Another request is that this work be compared to the kgi work so that we don't
repeat the same mistakes. I wasn't around for that debate, can someone explain
what was learned from attempt?
I'll start reworking the proposal to include the feedback I have so far and get
it ready for the next round.
--- Egbert Eich [EMAIL PROTECTED] wrote:
I fear that we will get a very Linux-centric view on device drivers.
This will leave us with device drivers for Linux and a different ones
Tell me the right non-Linux lists and I will post there too. There have been
significant complaints from the Linux
--- Egbert Eich [EMAIL PROTECTED] wrote:
Jon Smirl writes:
I'm putting together a document for Kernel Summit that describes
the issues
around graphics device drivers. The kernel developers are
currently making first
pass comments on it. As soon as I fold their comments in I'll
post
--- Egbert Eich [EMAIL PROTECTED] wrote:
Jon Smirl writes:
I'm putting together a document for Kernel Summit that describes
the issues
around graphics device drivers. The kernel developers are
currently making first
pass comments on it. As soon as I fold their comments in I'll
post
Jon,
This issue of whether or not to use kgi goes all the way back to design
decisions we made in 1998. Based on my recollection, I believe these
were the top issues:
1) kgi was Linux specific. We needed a kernel level module that was
more portable.
2) We wanted the bare minimum
On Thu, 6 May 2004, Jon Smirl wrote:
--- Jens Owen [EMAIL PROTECTED] wrote:
2) We wanted the bare minimum services in the kernel layer for
efficient and fast graphics support, and felt as much of the
driver code as possible should stay in user space.
Linux kernel people
On Thu, May 06, 2004 at 09:04:28AM +0200, Svante Signell wrote:
Also, is the S3TC issue resolved for the cards I mentioned before
Browse dri-devel archive, there was patch for software S3TC support.
--
Free Software - find interesting programs and change them
NetHack - meet interesting
John,
You can think of me as Old School, and take my feedback in that
context. My main reason for participating in this discussion is to give
some historical perspective.
Jon Smirl wrote:
--- Jens Owen [EMAIL PROTECTED] wrote:
2) We wanted the bare minimum services in the kernel layer for
Around 9 o'clock on May 6, Jens Owen wrote:
If you would like to get a flavor for the issue I'm writing about, simply
unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I
think you'll find many difficult issues crop up related to software fall
backs and efficient readback
--- Jens Owen [EMAIL PROTECTED] wrote:
Six years ago, most devices could not handle this type of restriction
efficiently. Things have improved on the high end; but the low end
devices, are still very similar to what we had back in the day. Even
today, I would be very cautious of deploying
Jon Smirl wrote:
Framebuffer access follows the rules; kernel calls are used to map it into user
space. The major violations in X are in PCI bus and graphics chip probing.
If mmapping is okay, then we're still able to touch hardware from user
space drivers. I'm fine with that.
I don't see any
Jon Smirl wrote:
--- Jens Owen [EMAIL PROTECTED] wrote:
Six years ago, most devices could not handle this type of restriction
efficiently. Things have improved on the high end; but the low end
devices, are still very similar to what we had back in the day. Even
today, I would be very
At the X Developers Conference there was a discussion of the issues around
framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
discussion. I'm going to try and list all of the issues I've heard from all
sides so some of the proposed solutions are in conflict. The goal
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
to support commercial Unices (like Solaris or
Martin Spott wrote:
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
to support commercial Unices
On Thu, 6 May 2004, Keith Whitwell wrote:
Jon Smirl wrote:
--- Jens Owen [EMAIL PROTECTED] wrote:
Six years ago, most devices could not handle this type of restriction
efficiently. Things have improved on the high end; but the low end
devices, are still very similar to what we had back
On Thu, 6 May 2004, Martin Spott wrote:
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
--- Vladimir Dergachev [EMAIL PROTECTED] wrote:
As far as acceleration - either 2d or 3d - it makes sense for it to stay
in userspace.
X and everything else needs to stop mapping the registers to user space and
instead start using an IOCTL interface to a driver. The problem is that X or
developers,
I am having experiancing a sementation fault when
calling glCompressedTexImage2DARB. I have checked the pointer returned from
GetProcAddress and it seems to be valid (not NULL). i placed a breakpoint in
teximage.c (a mesa source file) on the function
Sérgio Monteiro Basto wrote:
Hi
I find on internet morpheus-0.3 project.
and had had this problem:
#gdb morpheus
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
This GDB was configured as i386-redhat-linux-gnu...Using host
libthread_db library /lib/libthread_db.so.1.
(gdb) run
Starting program:
Mark Cass wrote:
developers,
I am having experiancing a sementation fault when calling
glCompressedTexImage2DARB. I have checked the pointer returned from
GetProcAddress and it seems to be valid (not NULL). i placed a
breakpoint in teximage.c (a mesa source file) on the function
--- Nicolas Souchu [EMAIL PROTECTED] wrote:
A major topic that I missed in the original list was how to handle BSD. DRM
is under the BSD license and FB is GPL. If these two code bases are merged,
what are we going to do about BSD? I don't know the appropriate BSD lists
to post this to so
On Thu, May 06, 2004 at 11:16:39AM -0700, Jon Smirl wrote:
At the X Developers Conference there was a discussion of the issues around
framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
discussion. I'm going to try and list all of the issues I've heard from all
Alex Deucher writes:
We also have to consider the trade off between the interfaces a modern
graphics driver needs verses maintianing multi-platform availability.
If linux merges the FB/DRM drivers and moves certain things to the
kernel, there is nothing stopping other OS kernel
On Thu, 6 May 2004, Jon Smirl wrote:
Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.
IIRC, the main reasons were:
- GGI wanted to do too much at once and was too intruisive (conclusion:
always advance in small steps,
The gdk_gl_query function comes in gtkglarea-1.2.2-17 rpm.
finding gdk_gl_query in code, only this lines in ./src/main.c
if( gdk_gl_query() == FALSE ) {
g_print( no OpenGL capability\n );
return 0;
}
Well, I deleted this 4 lines from code and morpheus works
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 7185)]
0x40328227 in XQueryExtension () from /usr/X11R6/lib/libX11.so.6
(gdb) bt
#0 0x40328227 in XQueryExtension () from /usr/X11R6/lib/libX11.so.6
#1 0x404c07b3 in glXQueryExtension (dpy=0x0, errorBase=0x0,
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
--- Nicolas Souchu [EMAIL PROTECTED] wrote:
A major topic that I missed in the original list was how to handle BSD. DRM
is under the BSD license and FB is GPL. If these two code bases are merged,
what are we going to do about
On Thursday 06 May 2004 15:58, Brian Paul wrote:
Mark Cass wrote:
developers,
I am having experiancing a sementation fault when calling
glCompressedTexImage2DARB. I have checked the pointer returned from
GetProcAddress and it seems to be valid (not NULL). i placed a
breakpoint in
I for one have been waiting to see much of the graphics driver moved to
the kernel as well. From a vendor perspective there is quite a lot to be
gained.
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever graphics system is required. Some
times
Around 16 o'clock on May 6, Sottek, Matthew J wrote:
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever graphics system is required. Some
times we need an X server, some times we need something more like a
framebuffer. Putting this in one
--- James Simmons [EMAIL PROTECTED] wrote:
2) Ben suggestion that we mount userland inside the kernel during early
boot and use a userland library. If we would use a library then it MUST
be OpenGL. This would be the forced standard on all platforms. This
would mean Mesa would be
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever graphics system is required. Some
times we need an X server, some times we need something more like a
framebuffer. Putting this in one place is a must.
'one place' appears to mean a common
Around 17 o'clock on May 6, Jon Smirl wrote:
A proposal has been made that OpenGL be promoted as the primary base graphics
API on Linux. Then things like Cairo and the xserver be implemented on top of
OpenGL.
I respectfully disagree with this plan. OpenGL should be the sole API for
--- Keith Packard [EMAIL PROTECTED] wrote:
Around 17 o'clock on May 6, Jon Smirl wrote:
A proposal has been made that OpenGL be promoted as the primary base
graphics
API on Linux. Then things like Cairo and the xserver be implemented on top
of
OpenGL.
I respectfully disagree with
Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.
IIRC, the main reasons were:
- GGI wanted to do too much at once and was too intruisive (conclusion:
always advance in small steps, not big leaps):
o
But who cares? Do you really intend to keep a common BSD and Linux API/code base?
Offering both solutions under BSD and GPL would be good for suggesting correct
license usage in the embedded world. GPL is too often bypassed.
What about a dual license.
The big reason for merging is memory
Around 18 o'clock on May 6, Sottek, Matthew J wrote:
I would contend that it is perhaps just a long held fear that mode setting
is too big and complex for the kernel.
With a library API instead of a kernel API, each driver author can choose
precisely where the split belongs.
I think you
44 matches
Mail list logo
