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 src/X8
On Fri, 11 Jun 1999 [EMAIL PROTECTED] wrote:
> On 7 Jun, Holger Waechtler wrote:
>
> > Hi Ralph,
>
> Thanks for the response! I'm having another go now that the new asm
> stuff has moved into the main branch.
>
> > The asm_???.c /.h /.S files are not used at this time. Take a look into
> >
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
> >
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 are
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 limiting themselves to Me
[EMAIL PROTECTED] wrote:
> However, looking at Make-config, I don't see -DMMX or -DUSE_MMX_ASM
> anywhere, nor in the lower-level Makefiles. Am I missing something?
> We can work around all this by disabling mmx entirely (and I guess we
> won't be missing anything :) but it would be nice to get t
On 7 Jun, Holger Waechtler wrote:
> Hi Ralph,
Thanks for the response! I'm having another go now that the new asm
stuff has moved into the main branch.
> 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
Brian Paul wrote:
>
> 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 tryin
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, a
On 10-Jun-99 Stephen J Baker 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 w
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
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 08-Jun-99 Holger Waechtler 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 ba
>On Tue, 8 Jun 1999, Holger Waechtler wrote:
>
>dlopen is really easy to understand:
Based on your explanation of uinx dl___() calls and my fairly extensive
knowledge of the Windblows counterparts I'd say it would take less than an hour
to hack a dlopen() interface on top of the Win32 API calls
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 lin
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 be
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 ve
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 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 h
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 c
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 t
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 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 seper
"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).
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 shoul
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 this:
>
> For a x86 ta
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 this:
For a x86 target, cmopile with -DUSE_X86_ASM -DUSE_MMX_A
Hi all,
It's a bit of a long story, but I'm working on adding autoconf support
to the g200/riva glx module, which integrates a hardware-accelerated
mesa into XFree86 3.3.3. We've run into a hitch with src/asm_mmx.c,
which #includes no header files, stalling compilation with -DMMX.
I don't unders
28 matches
Mail list logo
