Nouveau's Latest OpenGL 4.4 Extension Hits Mesa Git

[phoronix]

Phoronix: Nouveau's Latest OpenGL 4.4 Extension Hits Mesa Git

Just a few days ago I was writing about OpenGL 4.4's Query Buffer Object Support Appears Nearly Ready For Nouveau and as of last night that code is now in Mesa Git...

http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-Lands-Query-Buffer

[rastersoft]

Just a question: implementing an extension in the Intel side simplifies its implementation in the gallium side, or they are too much independent?

[pal666]

Just a question: implementing an extension in the Intel side simplifies its implementation in the gallium side, or they are too much independent?

any side simplifies(to some extent) other one

[duby229]

Just a question: implementing an extension in the Intel side simplifies its implementation in the gallium side, or they are too much independent?

The way I understand it is something like, The classic interface Intel's drivers use -is- the gallium3d OpenGL state tracker. Therefore any improvements Intel makes in the OpenGL implementation will be automatic, those improvements then simply need hardware support by radeonsi or r600g or nouveau..

[imirkin]

There are multiple levels of drivers - mesa drivers, gallium drivers.

i965 and the state tracker are mesa drivers (i.e. they both implement the mesa driver interface). The state tracker does things to operate the gallium drivers, which implement the gallium interface.

So mesa core (which calls into the mesa drivers as necessary) is shared by i965 and state tracker. Any improvements in the state tracker are only shared by gallium drivers.

For this particular series, I added core support (which mostly just calls a mesa driver-supplied callback), state tracker support to be able to call the proper gallium driver entrypoint (which I also added), and the nvc0 gallium driver backend implementation. The meat of this extension is in the hw driver backend, so while I did make things a teensy bit easier for i965 developers to implement this, the "hard" stuff remains to be implemented for them.

Other extensions can be different, whereby they are implemented entirely or almost entirely in the mesa core. Like the ARB_internalformat_query2 ext, which has a *ton* of stuff in core, and a very easily implemented driver callback.

[smitty3268]

Just a question: implementing an extension in the Intel side simplifies its implementation in the gallium side, or they are too much independent?

Like Illia said, it's heavily dependent on the extension in question.

Some extensions are 100% in shared code, while others are about 99% driver dependent. The majority are somewhere in the middle.

[iznogood]

I just checked on what each nvidia cards generation supports on opengl and how this is mapped on the nv50 and nvc0 drivers. As I can see all nv50 cards support only opengl 3.3 while nvc0 supports 4.5. This is how I saw it on wikipedia article, I am not sure if this is accurate though.
However a lot of extensions of gl 4+ are also ported to nv50 cards.
How is this possible?

[Kayden]

I just checked on what each nvidia cards generation supports on opengl and how this is mapped on the nv50 and nvc0 drivers. As I can see all nv50 cards support only opengl 3.3 while nvc0 supports 4.5. This is how I saw it on wikipedia article, I am not sure if this is accurate though.
However a lot of extensions of gl 4+ are also ported to nv50 cards.
How is this possible?

Some features purely extend the API, making it nicer to work with, and don't actually require any new hardware features. Alternatively, sometimes new extensions were introduced in the GL 4.x timeframe that old hardware could always do - it just was never exposed before. OpenGL makes it possible to implement extensions by themselves; each major version usually means "it supports some set of extensions" (more or less - I'm oversimplifying a little).

So that's totally possible.

[AJenbo]

I just checked on what each nvidia cards generation supports on opengl and how this is mapped on the nv50 and nvc0 drivers. As I can see all nv50 cards support only opengl 3.3 while nvc0 supports 4.5. This is how I saw it on wikipedia article, I am not sure if this is accurate though.
However a lot of extensions of gl 4+ are also ported to nv50 cards.
How is this possible?

Hardware is not build to support a specific API and only that API only, so think of it more as that the overlap between NV50 and OpenGL 100%, the rest only has partial overlap, so NV50 will never get full OpenGL 4.0 support, but may (and has) get partial support in witch case it will be able to run games that only require OpenGL plus thows bits from OpenGL 4 etc.