XFree86 and X.org are completely separate groups and have little to do with each other. The XFree86 core haven't left to go join X.org. The XFree86 core disbanded because most of the members were essentially retired and didn't do anything anymore. The core team disbanding was an acknowledgement that the core team didn't lead development anymore. The assertions made in this slashdot news article are a complete fabrication.
X is not an API. Xlib is an API, but it's not X. It's just a low-level interface to the X11 protocol. I'm not sure the original authors ever intended people to write directly to Xlib but to use toolkits built on top of it, and there are plenty of toolkits built on top of Xlib so you don't have to deal with Xlib directly. High level widgets have no business being in a low-level protocol interface. All your complaint indicates is that you chose the wrong level to write to.
All DX-8 software that the Xbox games use shipped on the game's DVD. DX-8 drivers undoubtly have bugs in them (all software has bugs) and the game is coded to those particular bugs, with workarounds and optimizations for that particular DX-8 driver. You can't change the DX-8 driver or the games will break.
That means that the Xbox games necessarily require the NVIDIA GPU. That dependency is in the games themselves. I can't imagine Xbox2 being able to emulate the NVIDIA GPU. It seems backwards compatibility really is not possible unless they also have the NVIDIA GPU on board (which is conceivable. PS2 has the PS1 chip in the box).
Why? Does the DRI support multiple screens yet? Multiple simultaneous cards? Does it support accelerated indirect rendering yet? What about workstation features like overlays or window IDs? Quad-buffered stereo? NVIDIA's drivers do all these things and the DRI still sucks like it did three years ago. NVIDIA was wise to stay away from it.
It's not a real game. People don't "play" 3DMark. I think part of the point of 3DMark was to show how games will perform on a particular card, but there are already in-game benchmarks that will show you more accurately how a game will perform on a particular card. And it is getting clearer that 3DMark doesn't reflect how a card will actually do on games in general since 3DMark scores are not correlated with game performance. Ideally, 3DMark performance should shadow game performance. The fact that it isn't would imply that 3DMark doesn't accurately represent how a game will perform. Sounds like 3DMark is a concept whos time has past.
This isn't true. That's a false rumor. Changing fairy.exe to quake3.exe doesn't do anything. Somebody said it once in some forum and alot of people were gullible enough to believe it. Try it, it doesn't work.
Nothing but rumors. Sites like the Inquirer post every rumor they hear, even when it's ridiculous. Remember when they were saying NV30 was definitely a two-chip solution. Remember people saying it definitely had a 256 bit memory interface? All it takes is one bozo posting to a forum and claiming he has inside information and the Inquirer will post it and you get dozens of fan sites acting like it was true.
You are going to see a problem with 32 bit processors shortly, namely that you run out of address space. While Pentiums can support more than 4 Gig of memory, each process can only have 4 Gig of address space. This includes mapped devices like video card framebuffers. Applications use more memory and more memory each year and with framebuffers growing too this compounds the problem.
Looks more like an app problem to me. Are they using ReadPixels for this benchmark? If they were it would likely use hardware acceleration. Looks more like they're just copying with the CPU from DDraw surfaces. If so, then they got expected results. I've seen around 200 MB/sec with ReadPixels using NVIDIA's binary drivers.
That IS the expected bandwidth you get copying from video ram to system memory with the CPU. Even having the graphics engine push the data across for you you'll only get PCI bandwith. This is a the way AGP is SUPPOSED to work. If they're claiming you should be able to get 1Gig/sec copying with the CPU or even with the graphics engine into main memory then they don't understand the way the technology works. That bandwidth only goes in one direction. It has nothing to do with drivers. This is the expected behavior for AGP. If they're copying with the CPU in their benchmark (and it looks like they are from those numbers), they got exactly the expected results. Methinks those guys just don't know what they're doing.
NVIDIA's binary drivers don't break between XFree86 versions. They support all XFree86 versions from 4.0.1 through top of tree XFree86 CVS. And they do have open source versions of the 2D-only drivers. The open source drivers support all NVIDIA cards. I've seen more complaints on XFree86 mailing lists about newer ATI cards not working that there are about new NVIDIA cards not working. I'd take vendor support over specs any day.
Codeplay is probably just upset because Nvidia is setting some precendece for graphics companies providing stuff like this free of charge to whoever wants it. It's got to be hurting Codeplay's business. It's obviously in Codeplay's favor if companies like Nvidia stay away from this stuff and leave it up to Codeplay so Codeplay can sell their proprietary commercial products to fill the gap. Other than dissent from Codeplay itself, Cg seems to be fairly well accepted by developers.
Codeplay was probably planning on making a DX9 backend for their commercial product, so Nvidia is just raining on their picnic. We'll see what happens to Codeplay over the next year or so.
These are Linux kernel issues. Linux just doesn't support AGP in a way suitable for stable operation on an AMD processor. Things should work just fine if you don't enable AGP. And some people have gotten things to work "mostly fine" by just disabling the large page extensions (mem=nopentium option). This is not a NVIDIA-specific problem.
You are mistaken. There is no such limitation in the X11 specification. Even XFree86 supports 10:10:10 framebuffers on some 3DLabs cards (see the man page on "glint").
All the X11 specification says is that there can be no more than 32 bits per pixel. This limitation only applies to core X11 rendering. Extensions like OpenGL do not have these limitations.
Re:Why won't nvidia play nice?
on
Linux on the iMac G4
·
· Score: 3, Informative
DVI is supported by the "nv" driver in XFree86 CVS, at least it is on PCs. See recent CVS checkins.
There aren't any advances to be made in optical
drives. We reached the diffraction limit years
ago. The diffraction limit comes long before the
superparamagnetic limit. You could do near-
field optics to beat that, but that has proven to
be difficult mechanically because of the close
proximity required between head and media.
I used to do that with Scanning Magneto Resistive Microscopy and Magnetic Force Microscopy in work at University that was supported by the NSA. Alot of very hard work, but there is potential to recover alot of data if the data was not carefully erased. "dd" won't do it. The biggest problems were in the area of spared out sectors and residual data in the guardbands. Modern disks have extra sectors that can be swapped with bad sectors when media problems are discovered at runtime. Through the drive interface you can only access *logical* sectors and not the bad sectors that have been replaced. There is mostly intact data at those places. Also, due to tracking misalignments there is typically long arcs of partial tracks of original data lying at the track edges after overwrite. Due to shock and temperature differences and other influences consecutive writes don't line up on top of each other. Careful erasing is a difficult problem.
Slashdot Mirror
You're either making that up or someone was misquoted. NVIDIA has made no indications of supporting anything other than XFree86.
XFree86 and X.org are completely separate groups and have little to do with each other. The XFree86 core haven't left to go join X.org. The XFree86 core disbanded because most of the members were essentially retired and didn't do anything anymore. The core team disbanding was an acknowledgement that the core team didn't lead development anymore. The assertions made in this slashdot news article are a complete fabrication.
X is not an API. Xlib is an API, but it's not X. It's just a low-level interface to the X11 protocol. I'm not sure the original authors ever intended people to write directly to Xlib but to use toolkits built on top of it, and there are plenty of toolkits built on top of Xlib so you don't have to deal with Xlib directly. High level widgets have no business being in a low-level protocol interface. All your complaint indicates is that you chose the wrong level to write to.
All DX-8 software that the Xbox games use shipped on the game's DVD. DX-8 drivers undoubtly have bugs in them (all software has bugs) and the game is coded to those particular bugs, with workarounds and optimizations for that particular DX-8 driver. You can't change the DX-8 driver or the games will break.
That means that the Xbox games necessarily require the NVIDIA GPU. That dependency is in the games themselves. I can't imagine Xbox2 being able to emulate the NVIDIA GPU. It seems backwards compatibility really is not possible unless they also have the NVIDIA GPU on board (which is conceivable. PS2 has the PS1 chip in the box).
Why? Does the DRI support multiple screens yet? Multiple simultaneous cards? Does it support accelerated indirect rendering yet? What about workstation features like overlays or window IDs? Quad-buffered stereo? NVIDIA's drivers do all these things and the DRI still sucks like it did three years ago. NVIDIA was wise to stay away from it.
It's not a real game. People don't "play" 3DMark. I think part of the point of 3DMark was to show how games will perform on a particular card, but there are already in-game benchmarks that will show you more accurately how a game will perform on a particular card. And it is getting clearer that 3DMark doesn't reflect how a card will actually do on games in general since 3DMark scores are not correlated with game performance. Ideally, 3DMark performance should shadow game performance. The fact that it isn't would imply that 3DMark doesn't accurately represent how a game will perform. Sounds like 3DMark is a concept whos time has past.
This isn't true. That's a false rumor. Changing fairy.exe to quake3.exe doesn't do anything. Somebody said it once in some forum and alot of people were gullible enough to believe it. Try it, it doesn't work.
Nothing but rumors. Sites like the Inquirer post every rumor they hear, even when it's ridiculous. Remember when they were saying NV30 was definitely a two-chip solution. Remember people saying it definitely had a 256 bit memory interface? All it takes is one bozo posting to a forum and claiming he has inside information and the Inquirer will post it and you get dozens of fan sites acting like it was true.
You are going to see a problem with 32 bit processors shortly, namely that you run out of address space. While Pentiums can support more than 4 Gig of memory, each process can only have 4 Gig of address space. This includes mapped devices like video card framebuffers. Applications use more memory and more memory each year and with framebuffers growing too this compounds the problem.
Looks more like an app problem to me. Are they using ReadPixels for this benchmark? If they were it would likely use hardware acceleration. Looks more like they're just copying with the CPU from DDraw surfaces. If so, then they got expected results. I've seen around 200 MB/sec with ReadPixels using NVIDIA's binary drivers.
That IS the expected bandwidth you get copying from video ram to system memory with the CPU. Even having the graphics engine push the data across for you you'll only get PCI bandwith. This is a the way AGP is SUPPOSED to work. If they're claiming you should be able to get 1Gig/sec copying with the CPU or even with the graphics engine into main memory then they don't understand the way the technology works. That bandwidth only goes in one direction. It has nothing to do with drivers. This is the expected behavior for AGP. If they're copying with the CPU in their benchmark (and it looks like they are from those numbers), they got exactly the expected results. Methinks those guys just don't know what they're doing.
NVIDIA's binary drivers don't break between XFree86 versions. They support all XFree86 versions from 4.0.1 through top of tree XFree86 CVS. And they do have open source versions of the 2D-only drivers. The open source drivers support all NVIDIA cards. I've seen more complaints on XFree86 mailing lists about newer ATI cards not working that there are about new NVIDIA cards not working. I'd take vendor support over specs any day.
Codeplay is probably just upset because Nvidia is setting some precendece for graphics companies providing stuff like this free of charge to whoever wants it. It's got to be hurting Codeplay's business. It's obviously in Codeplay's favor if companies like Nvidia stay away from this stuff and leave it up to Codeplay so Codeplay can sell their proprietary commercial products to fill the gap. Other than dissent from Codeplay itself, Cg seems to be fairly well accepted by developers.
Codeplay was probably planning on making a DX9 backend for their commercial product, so Nvidia is just raining on their picnic. We'll see what happens to Codeplay over the next year or so.
These are Linux kernel issues. Linux just doesn't
support AGP in a way suitable for stable operation
on an AMD processor. Things should work just fine
if you don't enable AGP. And some people have
gotten things to work "mostly fine" by just disabling
the large page extensions (mem=nopentium option).
This is not a NVIDIA-specific problem.
You are mistaken. There is no such limitation
in the X11 specification. Even XFree86 supports
10:10:10 framebuffers on some 3DLabs cards (see
the man page on "glint").
All the X11 specification says is that there
can be no more than 32 bits per pixel. This
limitation only applies to core X11 rendering.
Extensions like OpenGL do not have these
limitations.
DVI is supported by the "nv" driver in XFree86 CVS, at least it is on PCs. See recent CVS checkins.
There aren't any advances to be made in optical drives. We reached the diffraction limit years ago. The diffraction limit comes long before the superparamagnetic limit. You could do near- field optics to beat that, but that has proven to be difficult mechanically because of the close proximity required between head and media.
I used to do that with Scanning Magneto Resistive Microscopy and Magnetic Force Microscopy in work at University that was supported by the NSA. Alot of very hard work, but there is potential to recover alot of data if the data was not carefully erased. "dd" won't do it. The biggest problems were in the area of spared out sectors and residual data in the guardbands. Modern disks have extra sectors that can be swapped with bad sectors when media problems are discovered at runtime. Through the drive interface you can only access *logical* sectors and not the bad sectors that have been replaced. There is mostly intact data at those places. Also, due to tracking misalignments there is typically long arcs of partial tracks of original data lying at the track edges after overwrite. Due to shock and temperature differences and other influences consecutive writes don't line up on top of each other. Careful erasing is a difficult problem.