Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Jan 2008
Offline Last Active Today, 06:38 AM

Topics I've Started

I almost fell for this...

13 March 2014 - 08:45 AM

Woah! Dude! Seriously!


NVIDIA Dropping Pre-Fermi GPUs From Their Mainline Linux Driver

NVIDIA will be removing all support for graphics processors prior to the GeForce 400 "Fermi" series from their mainline Linux graphics driver.

There's a new posting on the NVIDIA Knowledgebase about "EOL driver support for legacy products." Beginning with the "Release 343" series (as of last week the 334.21 Linux driver is the latest available version) there is no GPU support prior to the GeForce 400 series and that's now been confirmed via this official NVIDIA.com entry.



That sounds like very serious news for Linux GPU support with immediate and present consequences. On the other hand, if you read the official statement, it reads a bit different:

  • will continue to support these products until April 1, 2016
  • future driver enhancements and optimizations [..] will not support these products

Read as: No new gimmicks, and no new features on pre-2009 cards which the hardware doesn't support anyway. Will continue to support these for (at least) 2 more years cards, after which these cards will be between 7 and 10 years old.


Man, it's always nice if  one reads the complete paragraph before publishing a big FUD headline... at least they also tell the correct details further down in the article.

Using IPv6 flow info

18 December 2013 - 08:44 AM

The socket structures for IPv6 sockets have a couple of "mostly useless" fields such as the scope id (which you only need to disambiguate link-local addresses) and flow info.


When trying to figure out whether I can actually scratch that seemingly useless info (not logging more than absolutely necessary in the DB, and 128bit addresses are already big enough), it turned out that flow info may not be all that useless at all.


Apparently, you have the option of setting it to a zero value, in which case it is ignored and packets are routed to the destination socket based on destination address and port. Or, you can set it to a chosen non-zero value, in which case the IP stack considers the packet being part of some group of packets that somehow belong together (a "flow").


It seems that hardly anyone uses flow info (there is very little info available, many people seem to consider it deprecated or useless or don't understand what it does) or assume that getaddrinfo will fill in something meaningful that they don't really have to bother about. It does, too, ... it fills in zero.


There exists, however, at least one person with name Black who suggests using flow info as a transport-layer nonce to prevent spoofing attacks. Also, according to the RFC, routers are strongly encouraged not to route packets that belong to the same flow via different routes.


The former does not truly convince me, but the latter actually sounds very interesting. If you can hint routers not to route your packets via alternating routes, you should be able to effectively minimize the number of duplicates you get at the receiving end. That alone might be enough of a reason to always set the flow control field to some random value when initiating a connection. If you only have IPv4 on one of the ends, it'll come out as zero anyway and be ignored, but if both ends are IPv6, this should really help some.

Is that assumption right?


As for being used as a transport-layer nonce, I would guess that if someone can figure that you have a connection of sorts on some port/address combination (which is necessary to spoof packets in the first place), then he can obviously read your traffic. Otherwise, how would he know? So the nonce would be trivially known and spoofable. Or am I making a wrong assumption there?

Stunned after reading a data sheet

07 November 2013 - 11:03 AM

I just read through the data sheet of a 4TB Seagate hard drive which says "Nonrecoverable Read Errors per Bit: 1 sector per 1014. Guess that's none better or worse than any other harddisk's error rate, only maybe you've never looked or the manufacturer doesn't publish it.

Anyway, this got me thinking, 1014 bits is only about 11.5 terabytes. It's a 4TB disk. Therefore, assuming you fill this disk using its complete capacity, there is an 1/3 chance that you have an unrecoverable defect sector. After only one complete write cycle? Note that the emphasis is on "nonrecoverable", I am certainly aware that one or the other bit may always flip by accident, that's just how things work -- but the drive's FEC will routinely correct that.
If you do 3 complete write cycles, you are statistically more or less guaranteed to have at least one nonrecoverable defect sector. Not seriously?

I must have some fallacy in my reasoning? Surely harddisks must despite all be a little more reliable than to allow 3 write cycles?

Weird shockwave stuff going on

01 February 2013 - 07:49 AM

The forum software on GD.net is always doing one or the other weird thing, nothing new there... but this week, it gets a bit more weird than usual, to an extent that ticks me off.

For the third time this week, I've been cliking on some topic from the "active topics" page only to be prompted by my browser that I want to open the file 6cuXgRVMvZ0 of type application/x-shockwave, and the browser doesn't know what to do with it (unsurprising, no shockwave installed).

Well, no, I don't want to run an unknown executable that I've not asked for.

Maybe this is just me being over-sensitive, but to me that's somewhat of a "WTF???" thing. Is that intentional?

Note: In case your first reaction is to assume this is your ad provider, that's likely not the case. I've gone to block everything on GD.net after getting the first "what to do with this file?" (ad-blocker on maximum, and scripting disabled), but I'm still being prompted for that file.

Texture swizzle

20 March 2012 - 07:21 AM

GL_ARB_texture_swizzle, which is core as of OpenGL 3.3 allows you to swizzle color samples according to texture state that you can set in the application -- before a shader sampling the texture gets to see them.

Which means you can write shaders that are agnostic of the actual channel layout of a texture as long as the application cares to set the state appropriately. For example, storing normal X/Y in green and alpha in a compressed texture, or using red and green instead from an uncompressed texture would work the same without the shader needing to know.

Now, how would I have to imagine this functionality? Should I think in terms of "driver secretly inserts swizzle instructions without me knowing", or should I think of "texture hardware can do this trivially anyway, and only needs to be told". The reason why I'm wondering is because if it's truly "free", then that's a feature just too good to be true. On the other hand, if it's a mere convenience thingie that impacts performance, one would probably rather have specialized shaders for each situation and do careful bookkeeping in order to batch them right.