Hi!
I think I found this one. Could you try latest CVS?
/Thomas
Julius wrote:
On Thu, 2 Sep 2004 10:45:03 +0200 (CEST)
Thomas Hellstrm [EMAIL PROTECTED] wrote:
Hi.
Still clueless, but I will try to fire up my KM400 this week and try to
reproduce your settings; in particlar
Is the VIA Unichrome the most open 3D chipset available?
--
Blood is thicker then water... And much tastier
John Davidorff Pell
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE
On Gwe, 2004-09-03 at 09:00, Rogelio Serrano wrote:
Is the VIA Unichrome the most open 3D chipset available?
VIA Unichrome graphic engine docs are NDA although some developers have
them. 3DFX Voodoo3 is probably the most open, then there are a couple we
have docs for and no drivers.
VIA Unichrome graphic engine docs are NDA although some developers have
them. 3DFX Voodoo3 is probably the most open, then there are a couple we
have docs for and no drivers.
Well if you are asking most open the i810/5 is, granted it isn't very
featureful and it quite slow, but the docs are
I went on a bit of a hack session this evening and the results can be
found in the drmlib-0-0-1-branch in CVS...
it is the basic start of a core library split, I've moved the buffers,
memory, agp, dma and proc into a lib.. this is a big hack at the moment,
and I haven't even looked at moving the
I have an ati 9000 on a asus a7n8x-x.
the direct rendering works well, and I can use glxgears, celestia and some other
application that need it, but a lot of games don't work.
For example when I try to start tuxracer the screen goes black and I can only exit
pressing esc. I can listen game's
On Fri, Sep 03, 2004 at 01:11:54AM -0400, Michel Dänzer wrote:
Hi Michel,
Well... however they are working, they're grown-up enough to deal with the
evolution of our codebase one way or another. Unless they actually make some
comment I don't think we need to try and guess what might
Did you use the dyn-minor patch? That will make splitting the stub code
off easier since I separated out the global vairables into an
independent structure.
--- Dave Airlie [EMAIL PROTECTED] wrote:
I went on a bit of a hack session this evening and the results can be
found in the
Dave Jones wrote:
2. 'The in-kernel AGPGART doesn't have all the features our driver requires'.
Newsflash: I take patches.
Sifting through the ATI mashed-up agpgart is quite painful, as there are
so many changes in there ifdef'd to hell and back that its hard to see
whats really needed and what
Alan Cox schrieb:
[...] then there are a couple we
have docs for and no drivers.
The Wiki mentions only the SiliconMotion Chips as having docs,
but no drivers, and says that SiS docs are available and a driver is
in development.
Are there any other chips with driver, without docs?
Philipp Klaus
Ian Romanick wrote:
Dave Jones wrote:
2. 'The in-kernel AGPGART doesn't have all the features our driver
requires'.
Newsflash: I take patches.
Sifting through the ATI mashed-up agpgart is quite painful, as there are
so many changes in there ifdef'd to hell and back that its hard to see
whats
As I said I didn't tackled the stub/global issues at all in this yet,
This is mostly building the leaf utility code as C files and linking it
into modules..
I'm starting to come up with a design that might be acceptable to all -
I'll do a write up soon and send it around for review.. I needed
Okay I've had some thoughts about the DRM interfaces and did some code
hacking (drmlib-0-0-1 branch on DRM CVS , very incomplete)
Below is my proposal for an interface that does introduce a major new
binary interface (the biggest issue with a straight core/personality split
for DRI developers,
I might move stuff like AGP support into the core. The core is the most
OS specific piece of code. So anything that is very specific to the
kernel API should be in it.
I would split like this:
drm_core - OS specific code, all global things
drm_library - shared code, not OS specific
driver
Then
Then drm_core would always be bundled with the OS.
Is there any real advantage to spliting core/library and creating three
interface compatibily problems?
Yes we only have one binary interface, between the core and module, this
interface is minimal, so AGP won't go in it... *ALL* the core
Will this redesign allow for multiple 3d accelerated cards in the same
machine? could I have say an AGP radeon and a PCI radeon or a AGP
matrox and a PCI sis and have HW accel on :0 and :1. If not, I think
it's something we should consider.
should be no problem at all, this is what I
--- Dave Airlie [EMAIL PROTECTED] wrote:
Yes we only have one binary interface, between the core and module,
this interface is minimal, so AGP won't go in it... *ALL* the core
does is deal with the addition/removal of modules, the idea being
that the interface is very minor and new features
--- Dave Airlie [EMAIL PROTECTED] wrote:
Will this redesign allow for multiple 3d accelerated cards in the
same
machine? could I have say an AGP radeon and a PCI radeon or a AGP
matrox and a PCI sis and have HW accel on :0 and :1. If not, I
think
it's something we should consider.
As we work towards the merged DRM/fbdev goal the fbdev libraries are
going to become part of DRM. The libraries will be used pretty much
unchanged as it is the driver code that needs to be adjusted. How does
this play with the new DRM model?
I think we have to remember licensing at all stages of this, the DRM is
X licensed, so I don't think we can just merge the fb code, I'm not sure
what peoples views on this, the main reason I see for using X licensing
is that we can share this stuff with FreeBSD and have an open source
graphics
If you're Nvidia you ship the library source (since it is GPL) and a
is it GPL though.. we are X licensed at the moment and all my changes are
under the original license...
binary driver. You compile the library on your kernel so that kernel
API IFDEF's get executed and then link to the
21 matches
Mail list logo
