Progress on TDFX driver...

[vykupitel]

Hello,
i'm interested if there is any progress on DRI TDFX driver. I think that we still doesn't have SLI support on Linux. From Daniel I know that SLI support was planned and former 3dfx engineer have some idea how to implement it.
Maybe would be better to post it on DRI-mailing list,but on this community forum are also skilled developers.Maybe someone would help

[dborca]

Hum,

there are some promises... but I dunno.
Anyways, I still couldn't find time to look at Linux since my failed attempt to write the server-side of miniglx for SOLO builds.

[vykupitel]

Oh,Daniel. Maybe news. Dieter Nuetzel from dri-maillinglist told me that he have a 'late' copy of the tdfx SLI tree.
Do you have the same sources?

[dborca]

I don't know Dieter.

I have the DRI, drm and Mesa sourcetree. I have some other sources as well.

I'm glad to see there are some news, but... I wish I had a nickel for every people that just "had" something. Well, obviously I'm exaggerating. I wish it was true. Capisci?

[vykupitel]

Yep, I understand you. Dieter promised me that he will send me that sources, so I will forward them to you of course.
Maybe that will help.

THX for your work Daniel.

[dborca]

I've updated the TDFX driver today. I haven't had the time to look into the DRI guts (hence SLI not working yet), but the driver itself worked pretty good on Mesa demos, GLExcess, Quake3 and UT2k3 demo.

[mateuscg]

Hello Daniel,
I tested your changes with a DRI snapshot from 20040722. With little time for testing I already see improvements in some things, with exception of a game called FooBillard (http://foobillard.sunsite.dk) (seems lighting problems, but I am a newbee in 3D :-) ). Well, I have not tested version 3.0 of the game before, but version 2.9 was running nice in Linux, with just one problem with the menu. The menu problem might be big texture sizes, according with the FAQ, but versions 2.9 and 3.0 of the game run without problems in Windows. I have Voodoo 3 3000 AGP 16MB, Windows 98 and Slackware 10.0, tested with Glide provided by distro and with binary release 3.10.00.30303 from glide.sf.net. A compiled package of the game for Slackware is available from http://www.linuxpackages.net. May be problem with Glide, DRI driver or Mesa? Do you have an idea?

[dborca]

Hi mateuscg,

Hehe, I'm running Slak, too

You have to understand a few things: about one year ago the TDFX driver was more advanced than the regular Glide driver. Since then, I worked only the Glide driver, totally neglecting TDFX. I thought it was time to fix it now, based on my experience, so it was only a week-end job. Please report me as many demos/games/apps as you can, preferably small pieces.

To whom it may concern: if someone has DEMOS from popular games, please send me the executable part only. Usually, the textures/data are shared between Win & Linux versions, and this would spare me from downloading hudreds of megs twice. Remember, I need DEMOS only.

EDIT: hmmm... about FooBillard... I wonder how did it work with previous DRI driver on Voodoo3. Because 2.9 and 3.0 use large textures for menu entries. The sw_rescale_hack is not enabled in TDFX yet. Anyway, it's kinda dumb, cos it doesn't test for max texture size. And even dumber because it's the first game I've seen that uses a separate texture for each menu entry. 99.9999999% of games out there "compose" text using small textures, each representing a letter.

[mateuscg]

Originally posted by dborca

Hi mateuscg,
...
Please report me as many demos/games/apps as you can, preferably small pieces.

I have only few apps to test: a Quake 3 demo, Tux Racer, Racer, emulators..., but I'm a very bad lucky guy because if something could go wrong, it would go wrong in my computer :-). Seriously, I hope someone else can test intensely this new DRI driver to make sure everything will run right.

EDIT: hmmm... I wonder how did it work with previous DRI driver on Voodoo3. Because 2.9 and 3.0 use large textures for menu entries.

Well, I need to clarify some things here: menu entries didn't work in versions 2.9 and 3.0 with Linux, only worked with Windows. The problem existed with previous versions of TDFX driver, before your recent changes. This game showed new problems, other problems, with your changes and I tested version 3.0 again to take some screenshots.

With Windows, works perfectly:


With TDFX DRI driver provided by distro (Slackware 10 - X.org 6.7):
- I haven't looked in config options to see if the white sides of the table are problems or not. There are two problems here: the menu entries and a black band in the field of the table that moves according of view angle. The black band didn't happen in version 2.9 with Slackware 9.1.


With TDFX DRI driver from 20040722 snapshot:
- The black band problem is fixed, but problems other than menu entries appeared, I think are lighting problems.

The sw_rescale_hack is not enabled in TDFX yet.

Menu entries showed right with Windows, so this is the method used by Windows drivers? Will fix the problem in Linux?

[dborca]

I'll try to look into the matter.

Yes, the SW_RESCALING_HACK does the job for Windows. Which MesaFX were you using?

[piriu]

Daniel, it's posible to make a control panel for all these options (sw rescaling, FXT1 to NCC conversion, other options...). Maybe also in Windows, because V3 3000 with it's small VRAM need some of these features. I mean for change on-the-fly or after a reboot.

Athlon 1700+
256 MB
V3 3000 AGP
Mdk 10.0CE/BeOS 5.0/W 98SE

[dborca]

Originally posted by piriu

Daniel, it's posible to make a control panel for all these options (sw rescaling, FXT1 to NCC conversion, other options...). Maybe also in Windows, because V3 3000 with it's small VRAM need some of these features. I mean for change on-the-fly or after a reboot.

The Mesa Control Panel does this job.

I see you're on W98SE. After hitting OK / Apply, you have to restart the filemanager (if any) or the open windows.

[mateuscg]

Originally posted by dborca

I'll try to look into the matter.

Yes, the SW_RESCALING_HACK does the job for Windows. Which MesaFX were you using?

I'm not using MesaFX. It's a "clean" Windows 98 install, with last official driver from 3dfx (1.07.00) and with last Glide3x release from glide.sourceforge.net (3.10.00.30303). If necessary, I can try with MesaFX, no problem, just have not installed it yet because I haven't used something that requires special features provided by MesaFX.

Mateus

[mateuscg]

Good news, I tested dborca's recent changes with a recent DRI snapshot (20040904) and the FooBillard regression bug was fixed.

The menu issue is the only problem left.

Daniel, I was testing some video players in Linux and discovered a problem: some settings are not available with the TDFX 2D driver. The driver doesn't support the minimum recommended XV (XVideo) atributes: XV_ENCODING, XV_HUE, XV_SATURATION, XV_BRIGHTNESS and XV_CONTRAST (taken from XFree86 server 4.x Design (DRAFT): The XFree86 X Video Extension (Xv) Device Dependent Layer). With your knowledge of 3dfx programming, could you take a look at this or give a tip about how this could be implemented (by example, which register could be changed to adjust the brightness setting)? I have found a patch for XV atributes implementation in Radeon cards and it didn't look too difficult, so maybe I can do the same in TDFX driver, but need some tips.

[dborca]

it just might be your lucky day/week/month. i'm almost finished transition from the windoze to the good ol' slack! so expect news in the linux area... ehm... more or less - as time permits.