glide-devel — Development discussion about the Glide project

Re: [Glide-devel] Linux kernel Staging Drivers project -- 3dfx

[J.R. M. <jr...@gm...>]

On Wed, Nov 12, 2008 at 3:14 AM, Hans de Goede <j.w...@hh...> wrote:
> Guillem Jover wrote:
>>
>> [ Adding the glide list to CC as other upstream developers might want
>>  to comment. ]
>>
>> Hi,
>>
>> On Thu, 2008-10-30 at 10:09:47 -0400, J.R. Mauro wrote:
>>>
>>> Hello,
>>>
>>> Greg Kroah-Hartman, the maintainer of the USB subsystem for the
>>> kernel, recently started a project to get out-of-tree Linux drivers in
>>> the mainline kernel faster. You can read an overview of Greg's
>>> announcement here:
>>> http://kerneltrap.org/Linux/Introducing_the_Linux_Staging_Tree
>>>
>>> The impetus for this is to make it easier for drivers that are not yet
>>> ready to be in mainline to become available so more people can easily
>>> contribute and use them. With the broader attention, drivers in
>>> staging will get the work they need and eventually 'graduate' and be
>>> moved out of staging. We're interested in gathering more drivers, so
>>> I've started contacting maintainers on his behalf. If you're
>>> interested in getting your 3dfx driver into staging or have any
>>> questions, please reply (keeping the CC: list intact).
>>
>> The current code can be found at:
>>
>>
>> <http://glide.cvs.sourceforge.net/viewvc/glide/Device3Dfx/?pathrev=glide-devel-branch>
>>
>> I think it has been mostly me maintaining it since 2003 or so and I
>> think it should be in a good shape now. But I'm not sure if it makes
>> sense to move into staging as this driver is only needed by the old
>> libglide2 and some of the forward ported hw support from libglide2 to
>> libglide3. The rest of libglide3 is using DRI instead, and I think
>> that's what the rest should be switched to, it just has not happened
>> yet. So if even then you think it makes sense to move the device3dfx
>> driver into the kernel staging then I guess it's fine with me as well.
>>
>
> I don't think putting Device3Dfx into the kernel is a good idea. The only
> thing it is needed for is to be able to run glide (or MesaGlide)
> applications on Voodoo 1 and Voodoo 2 cards as non root user.
>
> And if anyone wants to actually spend time on making Glide on Voodoo1/2 as
> non root user easier, then they should instead:
> 1) Write an initscript which chmod's the relevant memory regions under
> /sys/devices/pci......
> 2) Patch glide to do the mmap on the relevant memory represeting files under
> /sys/devices/pci...... instead of doing it on /dev/mem.
>
> Then Glide can be ran fine as normal user on Voodoo1/Voodoo2 cards, without
> requiring the hack known as Device3Dfx.
>
> More general drivers which do nothing more then allow userspace to map
> certain io regions should not be put into the mainline kernel, we alreayd
> have other mechanisms for that.
>
> Regards,
>
> Hans
>

Thanks for your replies; I'll update our drivers list with this information.

Re: [Glide-devel] Linux kernel Staging Drivers project -- 3dfx

[Hans de G. <j.w...@hh...>]

Guillem Jover wrote:
> [ Adding the glide list to CC as other upstream developers might want
>   to comment. ]
> 
> Hi,
> 
> On Thu, 2008-10-30 at 10:09:47 -0400, J.R. Mauro wrote:
>> Hello,
>>
>> Greg Kroah-Hartman, the maintainer of the USB subsystem for the
>> kernel, recently started a project to get out-of-tree Linux drivers in
>> the mainline kernel faster. You can read an overview of Greg's
>> announcement here:
>> http://kerneltrap.org/Linux/Introducing_the_Linux_Staging_Tree
>>
>> The impetus for this is to make it easier for drivers that are not yet
>> ready to be in mainline to become available so more people can easily
>> contribute and use them. With the broader attention, drivers in
>> staging will get the work they need and eventually 'graduate' and be
>> moved out of staging. We're interested in gathering more drivers, so
>> I've started contacting maintainers on his behalf. If you're
>> interested in getting your 3dfx driver into staging or have any
>> questions, please reply (keeping the CC: list intact).
> 
> The current code can be found at:
> 
> <http://glide.cvs.sourceforge.net/viewvc/glide/Device3Dfx/?pathrev=glide-devel-branch>
> 
> I think it has been mostly me maintaining it since 2003 or so and I
> think it should be in a good shape now. But I'm not sure if it makes
> sense to move into staging as this driver is only needed by the old
> libglide2 and some of the forward ported hw support from libglide2 to
> libglide3. The rest of libglide3 is using DRI instead, and I think
> that's what the rest should be switched to, it just has not happened
> yet. So if even then you think it makes sense to move the device3dfx
> driver into the kernel staging then I guess it's fine with me as well.
> 

I don't think putting Device3Dfx into the kernel is a good idea. The only thing 
it is needed for is to be able to run glide (or MesaGlide) applications on 
Voodoo 1 and Voodoo 2 cards as non root user.

And if anyone wants to actually spend time on making Glide on Voodoo1/2 as non 
root user easier, then they should instead:
1) Write an initscript which chmod's the relevant memory regions under 
/sys/devices/pci......
2) Patch glide to do the mmap on the relevant memory represeting files under 
/sys/devices/pci...... instead of doing it on /dev/mem.

Then Glide can be ran fine as normal user on Voodoo1/Voodoo2 cards, without 
requiring the hack known as Device3Dfx.

More general drivers which do nothing more then allow userspace to map certain 
io regions should not be put into the mainline kernel, we alreayd have other 
mechanisms for that.

Regards,

Hans

Re: [Glide-devel] Linux kernel Staging Drivers project -- 3dfx

[Guillem J. <gu...@de...>]

[ Adding the glide list to CC as other upstream developers might want
  to comment. ]

Hi,

On Thu, 2008-10-30 at 10:09:47 -0400, J.R. Mauro wrote:
> Hello,
>
> Greg Kroah-Hartman, the maintainer of the USB subsystem for the
> kernel, recently started a project to get out-of-tree Linux drivers in
> the mainline kernel faster. You can read an overview of Greg's
> announcement here:
> http://kerneltrap.org/Linux/Introducing_the_Linux_Staging_Tree
>
> The impetus for this is to make it easier for drivers that are not yet
> ready to be in mainline to become available so more people can easily
> contribute and use them. With the broader attention, drivers in
> staging will get the work they need and eventually 'graduate' and be
> moved out of staging. We're interested in gathering more drivers, so
> I've started contacting maintainers on his behalf. If you're
> interested in getting your 3dfx driver into staging or have any
> questions, please reply (keeping the CC: list intact).

The current code can be found at:

<http://glide.cvs.sourceforge.net/viewvc/glide/Device3Dfx/?pathrev=glide-devel-branch>

I think it has been mostly me maintaining it since 2003 or so and I
think it should be in a good shape now. But I'm not sure if it makes
sense to move into staging as this driver is only needed by the old
libglide2 and some of the forward ported hw support from libglide2 to
libglide3. The rest of libglide3 is using DRI instead, and I think
that's what the rest should be switched to, it just has not happened
yet. So if even then you think it makes sense to move the device3dfx
driver into the kernel staging then I guess it's fine with me as well.

regards,
guillem

Re: [Glide-devel] Device3Dfx kernel-2.4 compatibility

[Guillem J. <gu...@ha...>]

On Thu, 2007-01-25 at 13:40:16 +0200, O.Sezer wrote:
> Hello: Changes committed on 2006-12-03 broke
> compilation of Device3Dfx against 2.4 series
> kernels. The change in question is titled
> 'Rename functions obsoleted in linux 2.1.93':
> 
> 3dfx_driver.c: In function `doQueryFetch':
> 3dfx_driver.c:422: warning: passing arg 1 of 
> `pci_read_config_byte_R3ccefab4' makes pointer from integer without a cast
> 3dfx_driver.c:427: warning: passing arg 1 of 
> `pci_read_config_word_R923654cb' makes pointer from integer without a cast
> 3dfx_driver.c:432: warning: passing arg 1 of 
> `pci_read_config_dword_R0bf170e2' makes pointer from integer without a cast
> 3dfx_driver.c: In function `doQueryUpdate':
> 3dfx_driver.c:480: warning: passing arg 1 of 
> `pci_read_config_dword_R0bf170e2' makes pointer from integer without a cast
> 3dfx_driver.c:505: warning: passing arg 1 of 
> `pci_write_config_dword_R77f7f940' makes pointer from integer without a cast
> 
> I attached a patch that restores compilability.

Hmm, that's because those functions take 'struct pci_dev *' instead of
unsigned int even in older version, I'll fix this properly by using
pci_dev everywhere.

Thanks for the report!

regards,
guillem

[Glide-devel] Device3Dfx kernel-2.4 compatibility

[O.Sezer <se...@gm...>]

Hello: Changes committed on 2006-12-03 broke
compilation of Device3Dfx against 2.4 series
kernels. The change in question is titled
'Rename functions obsoleted in linux 2.1.93':

3dfx_driver.c: In function `doQueryFetch':
3dfx_driver.c:422: warning: passing arg 1 of 
`pci_read_config_byte_R3ccefab4' makes pointer from integer without a cast
3dfx_driver.c:427: warning: passing arg 1 of 
`pci_read_config_word_R923654cb' makes pointer from integer without a cast
3dfx_driver.c:432: warning: passing arg 1 of 
`pci_read_config_dword_R0bf170e2' makes pointer from integer without a cast
3dfx_driver.c: In function `doQueryUpdate':
3dfx_driver.c:480: warning: passing arg 1 of 
`pci_read_config_dword_R0bf170e2' makes pointer from integer without a cast
3dfx_driver.c:505: warning: passing arg 1 of 
`pci_write_config_dword_R77f7f940' makes pointer from integer without a cast

I attached a patch that restores compilability.

Regards,
Ozkan Sezer

Re: [Glide-devel] Voodoo Rush AT3D - Linux - The final truth

[Ryan U. <ne...@ic...>]

On Sat, Nov 04, 2006 at 07:18:58PM +0100, Francisco L. Fern=E1ndez Tortos=
a wrote:
>=20
> I could help you to debug your AT3D code because I have a working Linux=
 setup=20
> with that card (Alliance based voodoo Rush).
> I managed to compile Glide 3 and Mesa 6.2.1 (commenting out some AT3D c=
ode).
> But, of course, it segfaults on exec.

Well, I halted my project because Daniel Borca (or other person on this
list) notified me that the AT3D code could in fact be rewritten from the
non-releasable source, which somebody (I am uncertain who) has in their
possession.

> I think that is better to state from the beginning "this shouldn't work=
 with=20
> that hardware" and remove code and support than let the users face a pa=
inful=20
> and hopeless testing work.

Unfortunately with OSS, if the users are not willing to occasionally
become the developers then nothing ever happens.

> But if you want make work for the first time the Voodoo Rush with Linux=
 (I mean=20
> Open Source Glide / Mesa > 3.4.2) I am ready to help.

Thanks.  I'll let you know if I get bored enough to resurrect my RE
code.

--=20
Ryan Underwood, <ne...@ic...>

[Glide-devel] Fw: Voodoo Rush AT3D - Linux - The final truth - Forget this

[Francisco L. F. <flu...@gm...>]

Excuse me all.

Because the mailing list was silent since the last year, I supposed
that there was no activity in the CVS, but I have noticed that in the
last months someone has put some new files in the code.
Now it may  possible for the Voodoo Rush to work in Linux.
I am going to test it ASAP.

Begin forwarded message:

Date: Sat, 4 Nov 2006 19:18:58 +0100
From: "Francisco L. Fern=E1ndez Tortosa" <flu...@gm...>
To: ne...@ic...
Cc: gli...@li...
Subject: Voodoo Rush AT3D - Linux - The final truth


Ryan,

> On Sun, Jun 12, 2005 at 07:42:01AM +0200, Hans de Goede wrote:
> > Ryan Underwood wrote:
> > >This file never existed in the open source releases due to IP
> > >issues with Alliance.  I have reverse engineered the binary
> > >releases from a long time ago, but not completely rewritten or
> > >tested the code yet.
> > >
> >=20
> > Ah, I already had a feeling it could be something like this. Does
> > that  mean that sst96 support in CVS has never been tested?
>=20
> No.  Some (rare) cards with a Macronix controller do exist, I have
> one. However, I've not personally tested the current CVS.  It's on a
> todo list.
>=20
> Supposedly there was a prototype sst96 with a Trident controller, but
> I've never seen one nor is there any code to drive it.
>=20
> > Anyways I'll #ifdef 0 the Alliance code parts for now and throw an
> > error  if an Alliance is detected. That should get it compiling and
> > linking.
>=20
> This would be better than the current situation, where the library
> just mysteriously segfaults on an Alliance card.
>=20
> --=20
> Ryan Underwood, <ne...@ic...>

I could help you to debug your AT3D code because I have a working Linux
setup=20
with that card (Alliance based voodoo Rush).
I managed to compile Glide 3 and Mesa 6.2.1 (commenting out some AT3D
code).
But, of course, it segfaults on exec.

That is a funny thing. It seems that no one really has used the code for
years.
I could say that even apm XFree module doesn't work from version 4.0.1
onwards.
I had to switch back to XFree 3.3.6 release to be able to get video.
There is also a library (libXxf86rush) that has not been used for years,
and is
causing problem to some people compiling Xorg, although it is pretty
useless=20
nowadays. That is the problem of legacy code that is kept from previus=20
releases and supposed to work but never tested.

I think that is better to state from the beginning "this shouldn't work
with=20
that hardware" and remove code and support than let the users face a
painful=20
and hopeless testing work.

But if you want make work for the first time the Voodoo Rush with Linux
(I mean=20
Open Source Glide / Mesa > 3.4.2) I am ready to help.

Regards

[Glide-devel] Voodoo Rush AT3D - Linux - The final truth

[Francisco L. T. <flu...@gm...>]

Ryan,

> On Sun, Jun 12, 2005 at 07:42:01AM +0200, Hans de Goede wrote:
> > Ryan Underwood wrote:
> > >This file never existed in the open source releases due to IP issues
> > >with Alliance.  I have reverse engineered the binary releases from a
> > >long time ago, but not completely rewritten or tested the code yet.
> > >
> > 
> > Ah, I already had a feeling it could be something like this. Does that 
> > mean that sst96 support in CVS has never been tested?
> 
> No.  Some (rare) cards with a Macronix controller do exist, I have one.
> However, I've not personally tested the current CVS.  It's on a todo
> list.
> 
> Supposedly there was a prototype sst96 with a Trident controller, but
> I've never seen one nor is there any code to drive it.
> 
> > Anyways I'll #ifdef 0 the Alliance code parts for now and throw an error 
> > if an Alliance is detected. That should get it compiling and linking.
> 
> This would be better than the current situation, where the library just
> mysteriously segfaults on an Alliance card.
> 
> -- 
> Ryan Underwood, <ne...@ic...>

I could help you to debug your AT3D code because I have a working Linux setup 
with that card (Alliance based voodoo Rush).
I managed to compile Glide 3 and Mesa 6.2.1 (commenting out some AT3D code).
But, of course, it segfaults on exec.

That is a funny thing. It seems that no one really has used the code for years.
I could say that even apm XFree module doesn't work from version 4.0.1 onwards.
I had to switch back to XFree 3.3.6 release to be able to get video.
There is also a library (libXxf86rush) that has not been used for years, and is
causing problem to some people compiling Xorg, although it is pretty useless 
nowadays. That is the problem of legacy code that is kept from previus 
releases and supposed to work but never tested.

I think that is better to state from the beginning "this shouldn't work with 
that hardware" and remove code and support than let the users face a painful 
and hopeless testing work.

But if you want make work for the first time the Voodoo Rush with Linux (I mean 
Open Source Glide / Mesa > 3.4.2) I am ready to help.

Regards

[Glide-devel] Glide release

[Daniel B. <db...@3d...>]

Hi, 

I want to roll out the complete Glide sourcecode on SF.NET.
Maybe binaries, too.  If anyone wants to commit some changes
(Hiroshi? Hans?), please do it ASAP. 

Thank you. 

PS: Hiroshi, please PM me. 

Regards,
Daniel Borca 

[Glide-devel] binary file change in latest cvs

[O.Sezer <se...@gm...>]

Hello Hans,

I's pretty sure this isn't something you
intended, but my diff output says this:

Binary files glide-devel-20050702/glide3x/cvg/glide3/tests/lava.3df and
glide-devel-20050824/glide3x/cvg/glide3/tests/lava.3df differ

FYI.

Ozkan Sezer

[Glide-devel] Re: Glide3 h5 fifo code question

[Hans de G. <j.w...@hh...>]

I wrote:

---

Hi,

I've got myself a x86_64 system and I'm now reviewing the CVS Glide3
code for 64 bit cleanness.

The first warning gcc spew out turned out to be a speedbump, can someone
with better knowledge of the code take a look at the attched diff, and
then esp at the second chunk, there I did not only make it 64 bit clean
but really changed the code because the old code seems dead wrong.

Please comment.

Thanks & Regards,

Hans

---

A scrap it I thought the HW_FIFO_PTR() macro was a cast, which ofcourse 
it isn't. Reverting my stupid change.

Regards,

Hans

[Glide-devel] Glide3 h5 fifo code question

[Hans de G. <j.w...@hh...>]

Hi,

I've got myself a x86_64 system and I'm now reviewing the CVS Glide3 
code for 64 bit cleanness.

The first warning gcc spew out turned out to be a speedbump, can someone 
with better knowledge of the code take a look at the attched diff, and 
then esp at the second chunk, there I did not only make it 64 bit clean 
but really changed the code because the old code seems dead wrong.

Please comment.

Thanks & Regards,

Hans

[Glide-devel] 3dfxspl*.dll

[Ryan U. <nem...@ic...>]

Is the code for the 3Dfx splash screens sitting around anywhere in the
various Glide distributions?  I remember the first which was a '3Dfx
Interactive' that approached the user and spun, and then the latter
which shipped with the Voodoo3 drivers which was a more sinister looking
'3dfx'.

-- 
Ryan Underwood, <ne...@ic...>

Re: [Glide-devel] latest devel-cvs broken for cvg glide3

[O.Sezer <se...@gm...>]

Hello Hans,

Sorry for answering late,

Hans de Goede wrote:
> O.Sezer wrote:
> 
>> As for the Voodoo1 case, no matter what I did I couldn't
>> make 2005-06-10 snapshot to work.
>> 2005-04-04:
>> works with or without USE_X86=1
>> 2005-06-10:
>> without USE_X86: no way (black screen)
>> with USE_X86: as I told before, as soon as I start
>> drawing the scene the view freezes and I have to press
>> ctrl+alt+backspace and then do a soft reboot to get my
>> monitor back. In the log I got "FxMesa received unhandled
>> signal 1" and "unhandled signal 15"
>>
> 
> Hi,
> 
> I've been busy carefully studying a diff between current CVS and that of
> 04042005 and I found I've introduced 2 bugs (BAD!). So this is entirely 
> my fault. I did the warning fixes for sst1 last and I guess I was 
> getting tired.

I now the story well ;)

> Please checkout the latest CVS and try again with USE_X86=1 . Without 
> USE_X86=1 has never been tested but this wat not nescesarry with the old 
> version because the old version always assumed USE_X86=1.

Latest -devel tree (including today's changes) seem
to work fine for both voodoo2 and voodoo1 using X86=1.
Thanks for your good work.

Regards,

Ozkan

Re: [Glide-devel] latest devel-cvs broken for cvg glide3

[Hans de G. <j.w...@hh...>]

O.Sezer wrote:
> As for the Voodoo1 case, no matter what I did I couldn't
> make 2005-06-10 snapshot to work.
> 2005-04-04:
> works with or without USE_X86=1
> 2005-06-10:
> without USE_X86: no way (black screen)
> with USE_X86: as I told before, as soon as I start
> drawing the scene the view freezes and I have to press
> ctrl+alt+backspace and then do a soft reboot to get my
> monitor back. In the log I got "FxMesa received unhandled
> signal 1" and "unhandled signal 15"
> 

Hi,

I've been busy carefully studying a diff between current CVS and that of
04042005 and I found I've introduced 2 bugs (BAD!). So this is entirely 
my fault. I did the warning fixes for sst1 last and I guess I was 
getting tired.

Please checkout the latest CVS and try again with USE_X86=1 . Without 
USE_X86=1 has never been tested but this wat not nescesarry with the old 
version because the old version always assumed USE_X86=1.

Regards,

Hans

Re: [Glide-devel] Re: Glide3

[Ryan U. <nem...@ic...>]

On Thu, Jun 16, 2005 at 12:13:42AM -0500, Ryan Underwood wrote:
> 
> This would be better than the current situation, where the library just
> mysteriously segfaults on an Alliance card.

This would not be describing CVS.  This is what the open source glide2
does for sst96 with Alliance.  Sorry.

-- 
Ryan Underwood, <ne...@ic...>

Re: [Glide-devel] Re: Glide3

[Ryan U. <nem...@ic...>]

On Sun, Jun 12, 2005 at 07:42:01AM +0200, Hans de Goede wrote:
> Ryan Underwood wrote:
> >This file never existed in the open source releases due to IP issues
> >with Alliance.  I have reverse engineered the binary releases from a
> >long time ago, but not completely rewritten or tested the code yet.
> >
> 
> Ah, I already had a feeling it could be something like this. Does that 
> mean that sst96 support in CVS has never been tested?

No.  Some (rare) cards with a Macronix controller do exist, I have one.
However, I've not personally tested the current CVS.  It's on a todo
list.

Supposedly there was a prototype sst96 with a Trident controller, but
I've never seen one nor is there any code to drive it.

> Anyways I'll #ifdef 0 the Alliance code parts for now and throw an error 
> if an Alliance is detected. That should get it compiling and linking.

This would be better than the current situation, where the library just
mysteriously segfaults on an Alliance card.

-- 
Ryan Underwood, <ne...@ic...>

Re: [Glide-devel] latest devel-cvs broken for cvg glide3

[Hans de G. <j.w...@hh...>]

O.Sezer wrote:
> As for the Voodoo1 case, no matter what I did I couldn't
> make 2005-06-10 snapshot to work.
> 2005-04-04:
> works with or without USE_X86=1
> 2005-06-10:
> without USE_X86: no way (black screen)
> with USE_X86: as I told before, as soon as I start
> drawing the scene the view freezes and I have to press
> ctrl+alt+backspace and then do a soft reboot to get my
> monitor back. In the log I got "FxMesa received unhandled
> signal 1" and "unhandled signal 15"
> 

I've checked the 04042005 Glide3 version out from CVS and I'm currently 
comparing a diff between the two.

The first thing I've noticed is that I (accidently) changed the compiler 
flags from -O1 to -O2 can you edit sst1/glide3/src/makefile.linux and 
change the
OPTFLAGS ?= -O2 -ffast-math -mcpu=pentium
line to:
OPTFLAGS ?= -O1 -ffast-math -mcpu=pentium

Then do a realclean, followed by a build with USE_X86=1 set and test the 
result. That may explain your problems.

I made this error because the other trees (h5 h3) do use -O2. I guess 
the -O1 in sst1 is there on purpose becaue -O2 miscompiles it?

I hope this fixes it.

Regards,

Hans

Re: [Glide-devel] Re: Glide3

[Hans de G. <j.w...@hh...>]

Ryan Underwood wrote:
> This file never existed in the open source releases due to IP issues
> with Alliance.  I have reverse engineered the binary releases from a
> long time ago, but not completely rewritten or tested the code yet.
> 

Ah, I already had a feeling it could be something like this. Does that 
mean that sst96 support in CVS has never been tested?

Anyways I'll #ifdef 0 the Alliance code parts for now and throw an error 
if an Alliance is detected. That should get it compiling and linking.

Regards,

Hans

Re: [Glide-devel] Re: Glide3

[Ryan U. <nem...@ic...>]

This file never existed in the open source releases due to IP issues
with Alliance.  I have reverse engineered the binary releases from a
long time ago, but not completely rewritten or tested the code yet.

On Thu, Jun 09, 2005 at 04:24:54PM +0200, Hans de Goede wrote:
> Hi,
> 
> sst1/init/init96/initat3d.c seems to be missing from CVS, did somebody 
> forget todo a CVS add?
> 
> I've tried removing it from the makefile but that results in a linker 
> error in the end.
> 
> Regards,
> 
> Hans
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office luge 
> track?
> If you want to score the big prize, get to know the little guy.  
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Glide-devel mailing list
> Gli...@li...
> https://lists.sourceforge.net/lists/listinfo/glide-devel
> 

-- 
Ryan Underwood, <ne...@ic...>

Re: [Glide-devel] latest devel-cvs broken for cvg glide3

[O.Sezer <se...@gm...>]

Hans de Goede wrote:
>> This time my Voodoo2 works just fine with your latest
>> changes using USE_X86=1. Thank you.
> 
> 
> Good to hear, but I didn't change anything when compiling with USE_X86=1 
> all the changes are #ifndef GL_X86 . I think that you probably did a 
> make FX_GLIDE_HW=cvg realclean, or something which forced this and that 
> this solved your problems.
> 
>> Bad news is, Voodoo1 seems to need the same exorcism
>> because, with the latest snapshot, it gives me a black
>> screen without USE_X86. If using USE_X86, then my game
>> (hexen2) starts-up fine, but when the first triangles are
>> sent to the card, it just freezes.  Snapshot from april
>> 04 works fine (not using USE_X86, didn't try with it).
>>
> 
> Please try doing a "make FX_GLIDE_HW=sst1 realclean" before doing the 
> normal make and try again.

Hi Hans,

For Voodoo2, you may be right: My voodoo test box seems
to have gone crazy and gave me a fried memory module
yesterday, so my voodoo2 faults may be in error.
As for the Voodoo1 case, no matter what I did I couldn't
make 2005-06-10 snapshot to work.
2005-04-04:
works with or without USE_X86=1
2005-06-10:
without USE_X86: no way (black screen)
with USE_X86: as I told before, as soon as I start
drawing the scene the view freezes and I have to press
ctrl+alt+backspace and then do a soft reboot to get my
monitor back. In the log I got "FxMesa received unhandled
signal 1" and "unhandled signal 15"

Thanks,
Ozkan

Re: [Glide-devel] latest devel-cvs broken for cvg glide3

[Hans de G. <j.w...@hh...>]

O.Sezer wrote:
> 
> Hello Hans,
> 
> This time my Voodoo2 works just fine with your latest
> changes using USE_X86=1. Thank you.

Good to hear, but I didn't change anything when compiling with USE_X86=1 
all the changes are #ifndef GL_X86 . I think that you probably did a 
make FX_GLIDE_HW=cvg realclean, or something which forced this and that 
this solved your problems.

> Bad news is, Voodoo1 seems to need the same exorcism
> because, with the latest snapshot, it gives me a black
> screen without USE_X86. If using USE_X86, then my game
> (hexen2) starts-up fine, but when the first triangles are
> sent to the card, it just freezes.  Snapshot from april
> 04 works fine (not using USE_X86, didn't try with it).
>

Please try doing a "make FX_GLIDE_HW=sst1 realclean" before doing the 
normal make and try again.

Regards,

Hans

Re: [Glide-devel] latest devel-cvs broken for cvg glide3

[O.Sezer <se...@gm...>]

Hans de Goede wrote:
> Hi,
> 
> I now have fixed not only compilation but also linking of Glide3-cvs 
> with cvg without USE_X86=1. I hope anon cvs syncs soon so you can test 
> this.
> 
> Please notice that in the past when you compiled Glide3-cvs for cvg you 
> always got USE_X86=1, this was forced in the makefile because compiling 
> without this set was broken.
> 
> Besides that I wonder if you could also retest CVS with USE_X86=1 added, 
> as this doesn't crash (works fine) for me.
> 
> Regards,
> 
> Hans

Hello Hans,

This time my Voodoo2 works just fine with your latest
changes using USE_X86=1. Thank you.
Bad news is, Voodoo1 seems to need the same exorcism
because, with the latest snapshot, it gives me a black
screen without USE_X86. If using USE_X86, then my game
(hexen2) starts-up fine, but when the first triangles are
sent to the card, it just freezes.  Snapshot from april
04 works fine (not using USE_X86, didn't try with it).

Thanks again,
Ozkan

Re: [Glide-devel] latest devel-cvs broken for cvg glide3

[Hans de G. <j.w...@hh...>]

Hi,

I now have fixed not only compilation but also linking of Glide3-cvs 
with cvg without USE_X86=1. I hope anon cvs syncs soon so you can test this.

Please notice that in the past when you compiled Glide3-cvs for cvg you 
always got USE_X86=1, this was forced in the makefile because compiling 
without this set was broken.

Besides that I wonder if you could also retest CVS with USE_X86=1 added, 
as this doesn't crash (works fine) for me.

Regards,

Hans

Re: [Glide-devel] latest devel-cvs broken for cvg glide3

[O.Sezer <se...@gm...>]

Snapshot from 2005-04-04 works fine without USE_X86=1 (did
all my development under it), didn't try with USE_X86.

Ozkan


Hans de Goede wrote:
> I've been trying Glide3-cvs without USE_X86=1, but that doesn't work. 
> Now I understand why USE_X86=1 was forced in the makefile. So you really 
> should use USE_X86=1.
> 
> I'm trying yto get it to work without this, but I don't know if I'll 
> succeed.
> 
> Also nasm in Redhat used to have some problems and gcc-2.96 also might 
> be a problem. When is the last time you got Glide3-cvs to work?
> 
> Regards,
> 
> Hans
> 
>