Linux 7600 GT driver when?

[netllama]

The glXWaitVideoSyncSGI() issue should be resolved in the next driver release.

The "black stripes/flashes" problem was never reproduced, and we left off with you taking the action to provide me with a means of reproducing it. You also reported an FSAA problem on the GeForce 6150 which you had taken the action to provide a reproducible test case.

I'm not aware of any EDID issues, however I'd need a means of reproducing that as well.

Thanks,
Lonni

[morgoth]

Originally Posted by netllama

The glXWaitVideoSyncSGI() issue should be resolved in the next driver release.

Yes. This point is solved. Next.

Originally Posted by netllama

The "black stripes/flashes" problem was never reproduced, and we left off with you taking the action to provide me with a means of reproducing it.

It seems quite hard to reproduce without all pieces of software we run in our box. I didn't want to take time to write from scratch a program showing the problem because I suspect this problem to be linked to sync problems. We'll test next driver and we'll see: it's a bet. That's why I decided to spend more time testing kernel and drivers than writing GL stuff for nvidia to be able to reproduce the problem ! And as I wrote in a previous message, even if I had made all the work to reproduce the case in january, we wouldn't have more fix for this now.

That's where the problem is.

I never asked nvidia to reproduce all bugs and fix all of them in one night ! I just asked to have "normal" support, regular drivers and if possible betas between release versions.

That's not so much. It doesn't change anything to nvidia strategy and confidentiality. I even don't ask nvidia to release drivers as open source ! This kind of thought seems so evil for your company that I don't understand how I can still speak freely on this forum !

Why some betas on windows and not on linux ?

Why no patches for intermediate releases (not only for kernel module but also for X driver and gl/glx libs) ?

Originally Posted by netllama

You also reported an FSAA problem on the GeForce 6150 which you had taken the action to provide a reproducible test case.

This one should be easier to reproduce. Not a major issue for us, but still annoying for image quality. The problem happens while animating a textured object: the texture simply disappears partially. No repro case for now. No time for it. All our time was eaten by various tests with various GPUS, motherboards, kernels, drivers etc. Reread my initial message on this thread.

Originally Posted by netllama

I'm not aware of any EDID issues, however I'd need a means of reproducing that as well.

We had a mail exchange about this (on January 9 and 10 specially in a mail you sent on 01/10/06 03:47). We had issues when trying to boot with no monitor connected (even with DCC disabled). Ok: no problem: let's assume there's always a connected monitor to output. We had even worse issues: with a 42'' LG Plasma connected, DCC info was correct but Xorg didn't boot: frozen on a black console with a cursor on top left.

After some tests, you and I weren't able to reproduce the problem. But try to remember: you made some tests on this issue by trying to launch xserver repeatedly for hours with no freeze at all.

So this is still a potential issue, but we can't reproduce it in our respective labs: the bug happened on a customer site with a specific Plasma model. It's not your fault and it's not our: we both tried to reproduce the problem with no luck.
You did what we can expect from tech support. Nothing more to say on this point. We never had the problem again (because we never faced the same customer with the same screen probably). If we can make a test again, I'll let you know.

Thanks for answering again. I know your position is not comfortable. Mine is not either.

[morgoth]

No possible dialog ? Not even a customer claim ? Not a manager email even in private ? ...

[jpalko]

Originally Posted by phaseburn

Yea, I just bought a 7900 GTX and lost my X display because of it - no drivers... I'd very much like to know *when* drivers will be out as if it's not soon, I'm putting my old video card back in - but that's a lot of trouble I'd rather not go through if they'll be out in an hour or tomorrow or some time...

Working here with vesa driver of xorg-x11 rel7. Well, can't get huge resolutions and some other minor annoyances, but X works at least.

Though I am eagerly awaiting to get back to 1600x1200 with better drivers...

[prestidigitator]

Greetings. As you can see this is my first post to these boards. I have been developing software under Linux for some time (including OpenGL applications), but this is the first time I have really attempted to put together a full private system with up-to-date components. Here is a list of my relevant hardware:

• M/B: ASUS A8N-SLI Premium
• CPU: AMD Athlon 64 4000+
• Video: eVGA Geforce 7600GT CO
• Display: SAMSUNG 940t 19" LCD

I have installed Fedora Core 4 from DVD, selecting a custom install with all packages ("Everything"). I did not realize that the 7600GT is not yet supported under Linux.

1.) Are there any updates on this:

Originally Posted by spikebike

I see that monarch and newegg are selling 7600GT cards from numerous vendors. When should a linux driver be available?

2.) Given that the 7600GT is not fully supported, I am still not sure the behavior I am experiencing is correct. The only driver I can get X to start up with at all is the generic VESA driver. Using even the generic nVidia drivers shipped with FC4, X will not start (I have tried all of them). I installed the 1.0-8178 drivers available on the driver download page as described on the download page and not only will X not start, but since the GL/GLX libraries were replaced all GL applications will no longer work at all even when I switch back to the generic VESA driver (so I have uninstalled 1.0-8178).

Is this behavior to be expected, or should I be doing steps like those described in the Installing 1.0-8178 on Fedora Core 5 thread, or what?

Attached are the xorg.conf(.txt) and xorg.0.log files from just after I installed the 1.0-8178 drivers (I'm not sure there will be anything useful in them). I don't have a log file from the actual installer, but I can try to grab one again at some point if it is necessary.

(EDIT: The install did seem to be successful, BTW.)

Thanks for any help you can give!

[d13f00l]

Regarding the EDID bug, I think I have run into that as well.

I have EDID disabled, and I have set HorizSync and VertSync and MetaModes manually. When I bought my DFP, I could start X, but upon exiting X or switching VTs my system will die. My DFP will flash a pink bar flickering, my CRT flashes green green. I can't SSH into my machine, or anything. It's totally dead, and there's nothing in the kernel system logs.

Con Kolivas has also run into this, if he disables SMP I guess the problem goes away. His computer just totally locks. I have preempt enabled but I don't have an SMP machine, he thinks it's probably a race condition of some sort. I'm not sure if he's tried disabling EDID, I'll ask him.

Disabling EDID in the X Config seems to have cured the problem for me, I haven't had it happen, and it's been two weeks since I disabled it.

I own a 6200 AGP on an Epox 8rda, athlon xp 1.8ghz, a gig of pc3200 ram. X version 7.0, latest nvidia driver. This happened with X 6.8 as well, it's never happened before with my CRT, but maybe it's because CRT is now my 2nd head instead of first?

I've seen other threads about this as well, perhaps this can narrow the scope of the problem down?

[cruff]

It wouldn't be so bad that the 7600 doesn't yet have an accelerated driver if the VBE BIOS supported user specified CRTC values in the Set VBE Mode call. I have an ASUS EN7600GT board in an MSI Diamond Plus MB. Installing SUSE 10 finds the 1400x1050 and 1600x1200 VESA modes, but he stupid VBE BIOS only provides 60 Hz refresh! I can't look at it very long wihtout my eyes crapping out.

So, I modified the Linux startup code to attempt to set the refresh to a higher rate by setting bit 11 of the VBE mode to 1 to tell the VBE BIOS that I was passing in the CRTC settings via a pointer in ES DI. Doesn't work, the VBE BIOS ignores it, using the default 60 Hz refresh and doesn't even bother to return an error code.

[agriao]

Originally Posted by netllama

The glXWaitVideoSyncSGI() issue should be resolved in the next driver release.

The "black stripes/flashes" problem was never reproduced, and we left off with you taking the action to provide me with a means of reproducing it. You also reported an FSAA problem on the GeForce 6150 which you had taken the action to provide a reproducible test case.

I'm not aware of any EDID issues, however I'd need a means of reproducing that as well.

Thanks,
Lonni

Hello.

Sorry for going back some posts, but...
not able to reproduce the black/white stripes phenomena?
That's incredible.
Use just *any* KDE app, e.g, on an Geforve go 7300.
Furthermore, almost all the window managers around will show off the problem sooner or later.
KDE is immediate.
Fluxbox takes a few minutes.
Enlightenment e16 is a pure drunkard's walk (it may take a few seconds or not happen during a full session)

So far, the safer things i've tried are in descending order:
xfce
gnome

And I do mean "almost all the window managers around will show off the problem sooner or later". Poping a root/start menu is often enough.

This is posted in several threads. Just do a quick search on this forum.

Funny thing:

When using xfce/gnome and some app triggers the graphical chaos, it usually suffices closing it (or killing it...), switching to a non graphical shell and switching back to your running X environment.

Some people did some empirical workarounds for the 7300 GS using the previously released drivers.
See for instance the thread: http://www.nvnews.net/vbulletin/show...d=1#post850928

I fear i can't believe in naif statements like "we're never able to reproduce those / those were never communicated"

And no one here is up to personal attacking nor rage explosions.

Brand advertises to the wind its linux/bsd/solaris support > users buy and expect them to work. It's commitment. And it's a commercially established commitment. Straight an simple.
It's your game (nvidia's). You commit to develop your own closed source drivers so either u do, or you don't even release the boards.
In other business/lobby groups, juridical action would already have been taken.
It's just unexcusable.

[blender98]

Originally Posted by prestidigitator

2.) Given that the 7600GT is not fully supported, I am still not sure the behavior I am experiencing is correct. The only driver I can get X to start up with at all is the generic VESA driver.

If you do a modular xorg install, and pull xf86-video-nv from CVS, then it's possible to get the 7600 GT working with the nv driver (which certainly beats VESA). No 3D, but 2D works nicely.

It's essential to pull the nv driver from CVS, since it includes a number of fixes not in 7.0 (mostly patches to support PCI IDs in the 0x290 and 0x390 range). I ended up adding 0x391 (7600 GT) to the list of known PCI IDs, but there was no need to change the driver beyond this.

If you don't use the latest nv driver, you'll get your X server crashing on startup with signal 8 (SIGFPE), caused by division by zero when attempting to program the PLL frequency.

I *think* the latest XFree86 snapshots also have these fixes (since xorg pulled from the XFree86 tree).

[phaseburn]

Originally Posted by jpalko

Working here with vesa driver of xorg-x11 rel7. Well, can't get huge resolutions and some other minor annoyances, but X works at least.

Though I am eagerly awaiting to get back to 1600x1200 with better drivers...

And to those of us who can't do what we usually do under vesa, it isn't quite "working" :-/ But I do value your reply, thanks... For the time being, I just boxed my 7900 GTX up and left it sitting in my desk drawer... If anything it's a good lesson to avoid binge buying computer parts because I want the latest and greatest for once... Hehehe... Just hoping for sometime next week for drivers.

[netllama]

agriao,
The GeForce 7300 is currently unsupported in all released Linux drivers, and will be supported in the next released driver.

Its not clear to me what kind of problem you're reporting. On the GeForce 7300 systems that I have here, X will not start with 1.0-8178 (and this is expected behavior). Using an internal, unreleased driver which supports the GeForce 7300, I'm not seeing any problems in KDE. It seems unlikely that the problem you are reporting is the same as what one other person reported in a GeForce 6150, and more likely a result of using a driver which doesn't support the hardware.

I'm curious to see an nvidia-bug-report.log from your system.

Thanks,
Lonni

[zul646]

The thing I don't get is why don't you release your modified internal drivers as beta or even alpha? Seriously.

And what's the deal with Xgl? On the wiki I read that 7600GT is known to work well with Xgl and compiz (Both require 3D rendering and acceleration). And if Novell says so, they must have had some kind of access to the new 3D driver.

Anyway, I think we do deserve a beta driver.

Or maybe you could start some kind of beta-testing phase or somethin'. I'm in