I never had the need to mip-map a cube map until now. I find it interesting that GPU's don't provide downsampling from adjacent faces. Why isn't there an option?

Given my options are to render to a single texture with dimensions(cubeMapW*cubeMapH*6faces):

I feel like it will be inefficient if I have to render once to FBO,
Bind a new FBO 1/2 those dimentions, run a custom cube-map sampler

Bind a new FBO 1/2 the last ones dimensions, run a custom cube-map sampler

continue till we have a complete mip-chain

Maybe I'm wrong, I feel like the hardware generating mip-maps would be faster because it doesn't have to do the whole FBO thing and can just read from a single mip-map and write to another mip-map level.

As for generating the uv value for a cube-map, is there something better than this concept?

if(biggest component is x)
{
if(x is negative)
{

sampleFromCube(CUBE::NEG_X, vec2(y,z));

}
}
else if(biggest component is y)

{

}
else
{
}

I find it interesting that GPU's don't provide downsampling from adjacent faces. Why isn't there an option?

What do you mean? Texture filtering across faces? D3D10/GL3 era GPUs can do that. I forget the name of the GL extension though... it's on by default with DX11.

I feel like the hardware generating mip-maps would be faster because

There's no such thing as hardware generated mip-maps. If an API has a function to generate mip maps, then internally it's either drawing a bunch of quads with a downsample pixel shader, or dispatching a bunch of downsample compute shaders.
At least if you do it yourself, you know exactly what code is going to run and what your resulting quality is going to be -- different GL drivers will implement their magic mipmapping with different algorithms of different quality levels.

As for generating the uv value for a cube-map, is there something better than this concept?

Can't you just do: sampleFromCube(vec3(x,y,z))?

What do you mean? Texture filtering across faces?

It seems to be doing filtering across faces, but it wasn't mip-mapped using adjacent pixels. So one a sphere with the lowest mip-map it is just showing each face as 4 completely different colors, yes the edges of those are filtered a bit, but obviously the mip-generation should have average them to approach the same colors. Notice I said downsample (IE texture generation time) vs Texture filter.

Can't you just do: sampleFromCube(vec3(x,y,z))?

A cube map stored not as a cube-map but as all 6 faces in 1 rectangular texture? I need to create a custom lookup function in my own shader, not some hardware function.

I'm still on GL 2.0, I render to an actual cube map and call glGenerateMipMap(GL_TEXTURE_CUBE_MAP). So are you saying that in a newer version, or through extension, that it will generate mip-maps taking into account pixels in the adjacent mip-map? Otherwise it seems I need to do what I said and store this as a single 2D texture.

Thanks.

Those are for offline, not dynamic run-time generated cubemaps.

it wasn't mip-mapped using adjacent pixels. So one a sphere with the lowest mip-map it is just showing each face as 4 completely different colors, yes the edges of those are filtered a bit, but obviously the mip-generation should have average them to approach the same colors.

The built in mip-generation algorithms likely just use bilinear filtering. If so, and if your cubemap is a power of two, then there's no reason that any pixels on one face would influence the mips on any other face.
Bilinear filtering is terrible for downsampling, but it's cheap... If you've got a 1024x1024 texture with a yellow pixel at [511,511], by the time you've downsampled to 2x2 pixels, linear filtering will have made the top left pixel slightly yellow, but the other 3 wont be at all yellow whatsoever. This will be true for cube textures as well as 2D textures.

If you want quality mips, implement mip-generation yourself and use a good filtering algorithm.

So are you saying that in a newer version, or through extension, that it will generate mip-maps taking into account pixels in the adjacent mip-map? Otherwise it seems I need to do what I said and store this as a single 2D texture.

No - just that newish GPUs will filter across faces during sampling. Mip-generation using GlGeneratemipmaps has implementation-defined results - the spec doesn't say anything about what kind of algorithm/filter should be used.
Packing into 2D won't magically help anything.

If this is for your PBR/IBL stuff, the default filters reallt won't be good enough. For non-PBR IBL, a wider gaussian filter would be good enough, but for PBR you've got to use a convolution derived from your specular BRDF, as used by the offline tools above (you can use those filters at runtime too).

glEnable(GL_TEXTURE_CUBE_MAP_SEAMLESS).

This worked. I'm not sure if this is actually changing the downsampling for mip-maps but I think it may actually be the interpolation of the samples from the shader.