On 11 Jun, Holger Waechtler wrote:
Check it out again. I modified them to test at runtime, if the processor
is MMX-capable. The changes are both in the mainstream and the
experimental-1 branch sources.
The code in asm_mmx.c/.h is now translated to assyntax in src/X86/mmx.h
and
Jon Taylor wrote:
|... If the new generic interface can be implemented using a
| dynamic library based system, it would not necessarily have to be
| Mesa-specific. It could be implemented directly or as a wrapper layer
| around the GLX/WGL/etc interfaces, whether those interfaces
Stephen J Baker wrote:
On Thu, 10 Jun 1999, Jon Taylor wrote:
1. Linux (Unix) and Windows are, by far, the most popular platforms for
Mesa/OpenGL. The GLX and WGL interfaces are very well established.
Nobody will use a Mesa-specific interface instead of GLX/WGL since
they'd be
Thomas Tanner wrote:
First off, we'd need a unified driver API for Mesa.
Why has each driver its own API? This is bad.
There should be single interface for applications
so that they don't need to know the underlying driver.
I think you're off track here. What exactly do you mean by
On Thu, 10 Jun 1999, Thomas Tanner wrote:
2. There is the public interface which connects OpenGL/Mesa to the
OS / window system. This interface, by definition, is unique to
each system. These are the GLX, WGL, OS/Mesa, SVGA, Glide, etc
interfaces.
Yes. That's what I want
Thomas Tanner wrote:
I don't see why you're objecting to this idea.
I just want to implement support for dynamically loadable
drivers which requires replacing the old "kludges"
with another - in your opinion - "kludge".
I see the point you're trying to make. I guess the problems, as I
On 07-Jun-99 [EMAIL PROTECTED] wrote:
I don't see any autoconf stuff in the experimental-1 branch, but I did a
'cvs update -rautoconf' And tried that.
You need to `cvs checkout -rexperimental-1 .' (fresh checkout)
or `cvs update -PAd -rexperimental-1' (update)
Note that you always have to
On Mon, 7 Jun 1999, Thomas Tanner wrote:
I would be happy, if we could do something similiar with the FX/NV/G200
driver - Mesa would become a generic super-driver similiar to the SVGA
X-Server, which decides at runtime, which hardware driver it will use.
I think that'd be a very bad
Hi,
I just committed a portable assyntax version of gl_mmx_blend_transparency.
(src/X86/mmx_blend.S)
It's not used at this time, we have to create a hook first - (Keith ??)
The commented code in mmx.h is taken from blend.c - it does not works
since we habe to do this for every context.
The
On Tue, 8 Jun 1999, Holger Waechtler wrote:
Who says, that our super driver is not able to load it's subdrivers
dynamically ??
(could you explain, how dlopen() is used ?? - works it on non-Unix
platforms (MacOS, Dos, Windows) ?? -- if not, we could put some #ifdef's
around it and link at
Keith Whitwell wrote:
Holger Waechtler wrote:
Hi Ralph,
The asm_???.c /.h /.S files are not used at this time. Take a look into
the files in src/X86 instead (prefer the experimental-1 CVS branch,
there are the 3Dnow related things in this folder, too).
It should work once like
"Adam D. Moss" wrote:
Keith Whitwell wrote:
I believe that you can, as long as your binutils can cope.
and do the
test at runtime to decide which ones to activate?
Again, I read Holger's last paragraph to indicate that that is
what happens (correct me if I'm wrong).
I'm a bit
On 07-Jun-99 Keith Whitwell wrote:
I believe that you can, as long as your binutils can cope.
and do the
test at runtime to decide which ones to activate?
...
I'm a bit naive on the make options as I usually hack my own makefiles.
I was really referring to the need for the seperate
On Mon, 7 Jun 1999, Keith Whitwell wrote:
I think a better approach would be to compile everything
we are capable of do the checks at runtime.
That's exactly the thing I want to do. The linux-3dnow target is currently
the one which compiles in all available optimisations
On 7 Jun, Holger Waechtler wrote:
Hi Ralph,
The asm_???.c /.h /.S files are not used at this time. Take a look into
the files in src/X86 instead (prefer the experimental-1 CVS branch,
there are the 3Dnow related things in this folder, too).
Ah, I'd was curious why there'd been no cvs
On 7 Jun, Thomas Tanner wrote:
Please contact also Thomas Tanner, who is trying to write autoconf support
for Mesa.
... who has finished converting Mesa to autoconf.
I need testers, please !!.
Please checkout the experimental-1 branch or download the
current snapshot
Thomas Tanner wrote:
I think that'd be a very bad idea.
Let's try to avoid monolithic designs and select drivers via configure
options or, even better, make Mesa modular (a nice alliteration :) !
I could add portable dlopen support to Mesa, if you like.
Yes, I think this is the way to
17 matches
Mail list logo
