The interface that/dev/fb uses has ioctl:s for changing the resolution on the fly. vesafb can't use it though due to the complexity of using the VESA API from kernel space. If you are using for example matroxfb you can change resolution of the console at will.
The specs for the G400 isn't available as yet without an NDA though.
If 3d support under Linux is a must I'd wait with the G400 until I heard that the specs for the 3d part was released. (Or until matrox releases a working OpenGL driver for XFree86, whichever comes first...:))
Keep in mind that the specs for the G200 was released half a year after the card appeared in shops. In the 3d accelerator market half a year is a very long time... but on the other hand.. matrox did release the specs, let us hope that they continue to do that.
We can only access the framebuffer of supported video cards. Accessing the framebuffer really isn't that interesting since we can't send any 3d commands to the card via/dev/fb.
I mailed them in december 98 I think, and asked them about the rumors circulating about Linux support.(Some sort of library that would allow you to use the TNT under Linux)
I recieved a response that the rumors were correct, but that I wouldn't find anything on their website until it was ready.
Of course, PI's driver architecture isn't the entire answer. Even with no rendering functions Mesa isn't blazingly fast... so some work is probably needed on Mesa as well in order to get it to work....
In fact, in the long term, using Precision Insight's work might be the best idea.
Until the time of that release I guess that GLX is probably a good solution that isn't going to be extremely hard to port to PI's direct rendering architecture.
And even more important for some applications: The communication link between two computers is _way_ slower than the communication between two CPU:s on a dual board. You could of course use gigabit ethernet, but you can buy a dual PII for the price of one gigabit ethernet card..:)
Does anyone happen to have working code?
on
Friday Quickies
·
· Score: 1
Look at Terence Ripperda's page: http://reality.sgi.com/ripperda_engr/glx/
An updated version of the old mga-glx driver will probably be in the next release. It will probably still has some bugs, but it will be something to work from.
regards Andreas Ehliar
Mystique/Millenium 3D "suppoprt" is painfully weak
on
Friday Quickies
·
· Score: 1
hmm? read the specs a bit more careful the next time. the MGA core has always had support for a Z-buffer.
And the mystique has support for texture mapping as well, it just isn't mentioned in the specs for the mga1064. If you have a mystique 220 you might want to try some of the texture mapping registers of the G200 since they just might be compatible.
regards Andreas Ehliar
Where can you get PCI models??
on
Friday Quickies
·
· Score: 1
A free permedia driver already exists. It is still in alpha though. Look for MLX or ACL on the reference page on www.linux3d.org.
compiling all the packs at install time?
on
Friday Quickies
·
· Score: 1
FreeBSD is pretty interesting in this regard. Go to the source directory, update it to the latest version via cvsup and type make World and you'll rebuild every package. I assume that you can change CFLAGS and so on, but since I have never done this myself I don't know.
/AE
How long until we have 3D support under Linux?
on
Friday Quickies
·
· Score: 1
The project will be done using Mesa. The old driver for matrox millenium I cards is using the DD interface of mesa, but there has been talk of using MLX for the driver. MLX is still based on Mesa though, but it is intended to simplify driver development.
Anyway, there are a lot of things to be done before having a usable (as in being able to play q3test:)) driver.
It wouldn't surprise me a bit if the G200 is backwards compatible with the Mystique 220 in regards to 3d. Figuring out exactly what are supported on a 220 and what isn't is probably going to be quite boring, but not impossible.
I base this on the fact that the basic triangle drawing functions on the G200 is the same as on the old millenium I.
If only matrox would release the documentation for it...:/ Info coming soon they have stated on their website for close to 6 months now:(
ATI might not be such a good choice...
on
Voodoo3 Debut
·
· Score: 1
If you are using windows, ATI Rage 128 might be a good idea... if not, you lose. ATI does not seem very supportive of the idea of supporting 3d under Linux to say the least, heck, they don't even give out information on how to use the I2C bus on the 3d Rage II chip, which is needed to drive the ATI-TV card...:(
Regarding the banshee, Daryll is making progress on it according to his news page, and for the new voodoo3 board, they mentioned Linux as supported in the press release.
For news about 3d on Linux, particularly 3dfx related, look at http://glide.xxedgexx.com/
Slashdot Mirror
I read that the server port was running... but that a client port was unlikely
/Andreas
Doesn't quake use UDP?
Stands to reason that you wouldn't be able to connect to it via TCP then...
/AE
The interface that /dev/fb uses has ioctl:s for changing the resolution on the fly. vesafb can't use it though due to the complexity of using the VESA API from kernel space.
If you are using for example matroxfb you can change resolution of the console at will.
/Andreas
The specs for the G400 isn't available as yet without an NDA though.
:))
If 3d support under Linux is a must I'd wait with the G400 until I heard that the specs for the 3d part was released. (Or until matrox releases a working OpenGL driver for XFree86, whichever comes first...
Keep in mind that the specs for the G200 was released half a year after the card appeared in shops. In the 3d accelerator market half a year is a very long time... but on the other hand.. matrox did release the specs, let us hope that they continue to do that.
/AE
We can only access the framebuffer of supported video cards. Accessing the framebuffer really isn't that interesting since we can't send any 3d commands to the card via /dev/fb.
/Andreas
John Carmack did some experimenting with this,n c&id=11716
take a look at http://finger.planetquake.com/plan.asp?userid=joh
(The entry from 9/10/98)
I'm not saying that it would be impossible to do, but it is probably not that easy to do.
oh.. and shared memory is probably faster than unix domain sockets.
/Andreas
The only programmer writing code specifically for the TNT should be the programmer of the OpenGL library.
I mailed them in december 98 I think, and asked them about the rumors circulating about Linux support.(Some sort of library that would allow you to use the TNT under Linux)
I recieved a response that the rumors were correct, but that I wouldn't find anything on their website until it was ready.
/Andreas
Of course, PI's driver architecture isn't the entire answer. Even with no rendering functions Mesa isn't blazingly fast... so some work is probably needed on Mesa as well in order to get it to work....
/Andreas
In fact, in the long term, using Precision Insight's work might be the best idea.
Until the time of that release I guess that GLX is probably a good solution that isn't going to be extremely hard to port to PI's direct rendering architecture.
/AE
It is interesting to note that their so called "open source" website is using a proprietary webserver...
And even more important for some applications: :)
The communication link between two computers is _way_ slower than the communication between two CPU:s on a dual board. You could of course use gigabit ethernet, but you can buy a dual PII for the price of one gigabit ethernet card..
/Andreas
In fact, it is not NDA:d any longer.
/AE
Look at Terence Ripperda's page:
http://reality.sgi.com/ripperda_engr/glx/
An updated version of the old mga-glx driver will probably be in the next release. It will probably still has some bugs, but it will be something to work from.
regards
Andreas Ehliar
hmm? read the specs a bit more careful the next time.
the MGA core has always had support for a Z-buffer.
And the mystique has support for texture mapping as well, it just isn't mentioned in the specs for the mga1064. If you have a mystique 220 you might want to try some of the texture mapping registers of the G200 since they just might be compatible.
regards
Andreas Ehliar
A free permedia driver already exists. It is still in alpha though. Look for MLX or ACL on the reference page on www.linux3d.org.
FreeBSD is pretty interesting in this regard.
Go to the source directory, update it to the latest version via cvsup and type make World
and you'll rebuild every package. I assume that you can change CFLAGS and so on, but since I have never done this myself I don't know.
/AE
The project will be done using Mesa. The old driver for matrox millenium I cards is using the DD interface of mesa, but there has been talk of using MLX for the driver. MLX is still based on Mesa though, but it is intended to simplify driver development.
:)) driver.
Anyway, there are a lot of things to be done before having a usable (as in being able to play q3test
regards
Andreas Ehliar
It wouldn't surprise me a bit if the G200 is backwards compatible with the Mystique 220 in regards to 3d. Figuring out exactly what are supported on a 220 and what isn't is probably going to be quite boring, but not impossible.
I base this on the fact that the basic triangle drawing functions on the G200 is the same as on the old millenium I.
regards
Andreas Ehliar
If only matrox would release the documentation for it... :/ :(
Info coming soon they have stated on their website for close to 6 months now
If you are using windows, ATI Rage 128 might be a good idea... if not, you lose. :(
ATI does not seem very supportive of the idea of supporting 3d under Linux to say the least, heck, they don't even give out information on how to use the I2C bus on the 3d Rage II chip, which is needed to drive the ATI-TV card...
Regarding the banshee, Daryll is making progress on it according to his news page, and for the new voodoo3 board, they mentioned Linux as supported in the press release.
For news about 3d on Linux, particularly 3dfx related, look at http://glide.xxedgexx.com/