I wished for the Super Buffers this Christmas. And all I got were crappy presents I could buy in shop myself. In my disappointment, I doubt I'll ever write a letter to you again.

zeckensack

12-30-2003, 08:39 AM

I want my depth replace operations in ATI_fragment_shader ...

dorbie

12-30-2003, 12:38 PM

LOL, I suppose this thread should be in the OpenGl improvements section. How about framebuffer registers addressable in fragment shaders? Then you start to eliminate the fixed function framebuffer ops and write all that stuff in a single fragment program.

The alternative I suppose if yet another buffer fragment program extension with special instructions for ztest etc (yuck). Or maybe it just stays the way it is forever (doubt it).

knackered

12-30-2003, 01:17 PM

Not locking the thread dorbie?
Perhaps because it's started by a half-wit ripe to benefit from your projected wisdom about superbuffers?

QUOTE: "Anyone who proclaims a desire to be a moderator should be excluded from ever being appointed a moderator."

Obviously this age-old paraphrase meant nothing to the heads of the opengl.org management when addressing forum improvements. It's certainly ringing true now.
BTW, dorbie, my thread was a christmas joke, which of course you would know by now if it weren't for your celtic desire to have the last word coming to the fore again. Hence the need to butt into another thread - my apologies to the half-wit.
KLA!
Oh, and goodbye dorbie and all, and good luck with all your future work (not sure if that applies to you dorbie, you're a talker not a do'er aren't you?)

<knackered's very last post on opengl.org>
<knackered closed>

Jan

12-30-2003, 01:51 PM

Ah, stop that **** talking about moderators and locking each and every thread !!

Some time ago we didnīt have moderators and everything went well, except for A FEW threads which were off-topic AND ANNOYING !! (yes, i mean C++īs ones)

Now, we do have moderators for those RARE CASES, but now there are few threads left were not at least one of you guys demands that the thread gets be closed!

Moderators are ok, but donīt cry out for them everytime like little children !

I, and certainly most of us, donīt have a problem with most OT threads, as long as they donīt get offensive and silly.

As far as i can see, the moderators do a good job, so donīt tell them always what to do and who to ban, whatever.

Just my 0.5 Euro.

Jan.

dorbie

12-30-2003, 02:10 PM

This is just your latest personal and viciously attack knackered. It doesn't take much to set you off and once more your attacks say more about you than me, it's a shame because I thought you'd made a breakthrough a while back. Sigh.

One of the perils of anyone posting with their real identity online is that there's always some nut out there who will throw a tantrum and hide behind their anonymous handle.

I've been a graphics programmer for years and have done more than you'll ever know about, I'm not just a talker and take pride in my accomplishments.

I don't know if this will settle down, but frankly this ain't worth the aggravation. I may resign from this moderation malarkey. I was asked to do this after being nominated by other frequent contributors (AFAIK) I didn't push for it although I've been pretty frustrated at times by the lack of moderation.

The idea that we can or cannot have light hearted threads and every thread must be held up to the standard of every other is not something I can be bothered worrying about.

Moderators have email addresses you CAN email and offer feedback and even request threads be opened closed moved etc. before venting your spleen all over the boards. Having your joke thread requesting more moderation closed (have you no sense of irony!) is not like killing your first born. And the first week of moderation does not have to be the benchmark for all time if you offer feedback beyond self indulgent twaddle.

i agree with jan when he says that most people don't mind OT posts. the way i see it, opengl.org is a community for people who are interested in opengl programming, a place where we can help each other out and swap ideas. and who does it harm if somebody asks for help that isn't strictly opengl related? for example, a while back there was a thread where someone was asking for monitor recommendations. sure, not exactly opengl, but here we have a great body of people with applicable experience -- why not ask for some opinions? maybe that person didn't know where else to turn, or maybe they would rather ask people they know than complete strangers on some other forum. and if you don't like OT threads, then don't read them... most people are explicit in the titles, so it's not like it's hard to determine which posts are going to be opengl related. and if the thread manages to stay at the top... well then obviously enough people were interested to keep it going. the whole concept of sorting threads based on the last post date is a democracy in-and-of itself. now sure, the system can be abused -- say if one person keeps adding more and more to their own thread to send it to the top -- and in that case, the moderators should step in. there are other instances where moderation is necessary as well (for example, spam). and moderators can also help by moving threads to a different forum -- in the interest of helping the poster by gaining them exposure to an audience more geared towards their topic. but the moderators shouldn't have to police the threads -- their job shouldn't be "hard work", it should be to lend a hand when and where they can. they were selected to be moderators because they have knowledge in the realm of opengl, not because they're trained in law enforcement.

hmm, probably a few too many cents shared :P
-henry

SirKnight

12-30-2003, 07:21 PM

hmm, probably a few too many cents shared :P

I'd say enough to buy a bucket of chicken at KFC. http://www.opengl.org/discussion_boards/ubb/wink.gif

mmm. Chicken.

-SirKnight

Stephen_H

12-30-2003, 08:12 PM

What hardware will superbuffers be available on? Is it just a matter of adjusting drivers, or does it actually require specialized hardware?

If I understand the extension, it would be incredibly useful if I could cache my boned models vertices between different light passes to reduce the transform burden.

Hull

12-30-2003, 08:25 PM

What exactly can a superbuffer do?

and why is it called 'SUPER'-buffer.

Why not 'yet-another-extra'-buffer,
or maybe 'Have-not-a-clue'-buffer?

Knackered is dead, long live the Dorbie!

Zengar

12-31-2003, 12:58 AM

Well said, lost hope!

davepermen

12-31-2003, 04:17 AM

Originally posted by Hull:
Knackered is dead, long live the Dorbie![/B]

Glslang is still in its infancy; promoting it to core without even having had an implementation that works for a time would be a bad move. Better to have no core programmability than to have bad programmability. Glslang, like all features, needs to prove itself before becoming core.

Besides, being part of the core doesn't mean too much these days, as many people rely on extensions. The extension mechanism is a handy way to querry the avaliability of certain hardware features on a per-feature basis. Also, promoting glslang to the core doing so would mean that older hardware (pre R300/NV30) wouldn't be able to implement the newer spec in any meaningful way. Better to wait until more hardware out there can actually run glslang at a reasonable speed first.

As for Knackard, who cares? He was a useful contributer, certainly, but if he couldn't deal with the idea of having moderators that err on the side of leaving threads open, then he should leave. Better than being here disrupting the forum by complaining.

JD

01-02-2004, 03:53 AM

Gl arb shaders are fine. The only thing that lacks a bit is hlsl and glslang will fix that(already happening with ati). At least on windows the gl core is useless. I certainly don't want to wait for MS and SGI to release updated gl interface/docs. I rather have the ihv do that themselves, it's quicker that way. You get used to browse sgi core specs along with ihv ext specs. It's really the best this way. I mean, some exts have never made it to the core and they're ages old now.

V-man

01-02-2004, 10:43 AM

ok, VBO is significant for behind the scene, but the future is programmability for the sake of visual effects.

Let's list what's new in 1.5 :

ARB_vertex_buffer_object
ARB_occlusion_query
EXT_shadow_funcs

yup, that's it!

Which makes 1.5 uninteresting.

Geez, there are professional software out there using ARB_vp ARB_fp.
Carmack announced a long time ago he has a path for ARB2.
Companies (marketing!) are writing supports GL 1.4 and whatever.
So are games on there system recommendation list.

dorbie

01-02-2004, 11:54 AM

Whether a spec makes it to core isn't entirely to do with maturity and age. It is tightly coupled to the politics of what the various hardware vendors can support (and their perception of impact on their hardware sales). You just don't get anything promoted to core that forces significant numbers of IHVs (any?) off the latest OpenGL revision. Heck even the conformance tests are tied to politics in similar ways.

The whole reason ARB extensions were initiated anyway was to allow vendors some slack. Now people are saying ARB extensiosn as a way of introducing new features without the finality of core. That's always what EXT extensions were supposed to be. ARB was supposed to be core but optional features, and it's a political concession.

As all vendors adopt commodity GPUs this may improve for the simple reason that they'll be forced kicking and screaming to support more features, and extensions will in general become more significant hardware features and will be less numerous thanks to programmability eliminating the need for them.

The dust is still settling on GPU programmability though. It's pretty clear that there are important parts of the pipeline that aren't even programmable yet.

Nonetheless, ARB is core optional (so all those dinosaur CAD vendors stay on board), and if it isn't then someone explain why we have ARB and EXT extensions.

JD

01-02-2004, 12:38 PM

I've seen lately ext being superseeded with arb. There are also those os specific extensions xgl/wgl,etc. that we need and which aren't in the core.

Korval

01-02-2004, 02:09 PM

Geez, there are professional software out there using ARB_vp ARB_fp.

And? You shouldn't put something in the core that is likely to be superceeded by something else that you want to put into the core. It's the same reason why CVA's never made it to core (besides the fact that the extension itself is poor at best).

The fact that, on Windows implementations, you have to access recent core features via GetProcAddress like a regular extension means that there is very little difference between a widely adopted extension and a greater-than 1.1 core feature.

dorbie

01-02-2004, 02:33 PM

Good point.

I wonder if it's time for the ARB to take control of the OpenGL entry points to give native 1.5 (and future) bindings. I mean the drivers are there. The main obstacle is the stagnant OpenGL32.dll, would it be possible to go with an OpenGLARB.dll that we can all link to and redistribute with our apps that keeps pace with ARB developments subsequent releases would rev the contents and installation scripts would check the version. IHVs could support it and heck you could even wrap it around OpenGL32.dll legacy libs, you wouldn't even need full IHV buy in.

Is this even a major issue?

[This message has been edited by dorbie (edited 01-02-2004).]

Jan

01-02-2004, 03:25 PM

Actually, why do we need an updated OpenGL32.dll, at all?

I mean, it works, doesnīt it? Ok, itīs a bit complex, but we do have libs for that (Levīs extensions loading library, GLEW, etc.).
Using such libs itīs VERY easy to work with extensions.

But now think of the situation, when there IS an updated dll. Now everyone might have different dlls. So your app has to check that. And if there is an old one, you either have to force the user to update it, or you have to do it yourself or whatever. Even though the driver might support new extensions the user might have the wrong dll.

The way it is done at the moment works very well, why do we need to change that? I am waiting for OpenGL 2.0 and then everything will get updated and cleaned up. After that we can again use the extension mechanism, it has proven to be a very good solution.

BTW: Why would you want to have an ARB-dll, if you might use non-ARB extensions anyway. You still have to handle extensions, so handling the ARB extensions too, would be no problem.

Bye,
Jan.

dorbie

01-02-2004, 05:50 PM

The reason I said a new ARB dll is because the entry points for OpenGL32.dll are Microsoft's and you can't mess with that. I dare say you'd fail any WHQL if you replaced it etc (AFAIK, it's not really my area). ARB would be a COMPLETE REPLACEMENT for OpenGL32.dll, a separate lib that effectively did the same thing. You just link to it instead and it's managed by the ARB, written as a collaboration between the IHVs and released each time an OpenGL release is made. It would coexist with the deprecated OpenGL32.dll for legacy linked apps.

As for different dll's there's no need to check, it's called backwards compatability. Subsequent releases would be a superset. Installation would install up to the version an application required but would not clobber later versions. Future versions would work. Just as OpenGL32.dll remained compatible with OpenGL 1.0 & 1.1 linked apps. Didn't affect them a bit that OpenGL32.dll got updated they remained 100% binary compatible.

The way it's done now does not work particularly well, but your mileage depends on which calls you use.

The major difference is that EVERY application that linked to the ARB dll would ship it as a redistributable (remember it could wrap OpenGL32.dll as a fallback) and check versions on installation you don't want to roll back newer libs), add to that IHVs shipping it with their drivers and you'd have pretty good coverage.

The other way to go would be multiple versioned libs instead of one to avoid and possibility, but it wouldn't link automagically without a wrapper.

[This message has been edited by dorbie (edited 01-02-2004).]

Korval

01-02-2004, 07:44 PM

I am waiting for OpenGL 2.0 and then everything will get updated and cleaned up. After that we can again use the extension mechanism, it has proven to be a very good solution.

You're likely going to be waiting a long time. There probably won't be an official GL 2.0, as the impetus for it is no longer there. We have VBO's, and now glslang. The primary functionality missing that GL 2.0 would have provided will be filled in by superbuffers.

dorbie

01-02-2004, 07:56 PM

The assumption that everything will get cleaned up with 2.0 is also flawed. Microsoft left the ARB, are they going to update the legacy opengl dll? No. Just like they haven't touched it in years, in fact the last dll update rev was done by SGI and part of a broader agreement.

So any cleanup or update would be along the lines of the above suggestion, done by coorerating IHVs.

FWIW I agree 2.0 won't happen now, (and that may not be a bad thing).

V-man

01-02-2004, 08:29 PM

I think the diff between EXT and ARB was that EXT can come from a single vendor and is marked as EXT to encourage others to implement (my memory might be fuzzy) and ARB comes from the ...

As for what I was saying previously,
Let me quote something from the meeting notes

"ARB_vertex_program and ARB_fragment_program :

VOTE for inclusion in the core: 1 Yes / 0 Abstain / 9 No, FAILS.

Need to decide how to handle this short of the core"

Short is right my friend!

mw

01-03-2004, 03:52 AM

I don't think that the way OpenGL is handled via the OpenGL32.dll is too bad: on every system you can be sure, that at least OpenGL 1.1 is supported (even if it is done by software).
What entry points should a "new" OpenGL32 (or OpenGLARB) dll provide? All core functions up to 1.5? All ARB extensions? All extensions defined by now? If a video card doesn't support an extension, should it be emulated in software?

If one needs (in Windows) a rich OpenGL software implementation, one can use MesaGL - and if extensions or higher-than-OpenGL 1.1 functions are needed, one must check for them anyway, since the video card may not support them - the small extra work to get the corresponding entry points is not too important in my opinion than. (Compared to the work to implement different code paths).

P.S. I think OpenGL 1.5 was designed quite nicely: Maybe I would not have included ARB_occlusion_query, and maybe I would have included ARB_xxx_program, since this extension could be easily emulated by every GLSLang compatible video card, but does not need that much flexibility. So it could be kept as a "compatible to nearly everything" fallback option for simple shaders - as MesaGL and NVidia show, an implementation can be done in software too (very much like 3D-Textures which are slow as hell on "OpenGL 1.4" compliant Geforce4mx).

Jan

01-03-2004, 04:13 AM

Originally posted by dorbie:
The assumption that everything will get cleaned up with 2.0 is also flawed. Microsoft left the ARB, are they going to update the legacy opengl dll? No. Just like they haven't touched it in years, in fact the last dll update rev was done by SGI and part of a broader agreement.

Yes, i know, that we have to wait quite some time for OpenGL 2.0, and i really hope that it does not get dropped completely.

Of course MS will do everything to prevent any OpenGL update. But i am quite sure, that they could be forced to let it get updated. Remember what Netscape did against MS ? They simply went to court, because MS was not playing by the rules. And Netscape won. If SGI would care at least a little bit about OpenGL on windows, they would do the same. But my impression is, that they sit on their fat ***** and simply donīt care about anything.

Jan.

mw

01-03-2004, 07:30 AM

I don't think that Microsoft could (or should) be forced to implement OpenGL drivers.
If they would provide no easy mechanism, it would be their miss, since OpenGL is a great API which is widely supported.

I hear that OpenGL drivers are not HW accelerated on Windows XP default drivers, and maybe OpenGL support will be skipped at all somewhen (not that it seems that Microsoft has put in any work in the last few years) - then it's the responsibility of OpenGL supporters (such as video card vendors and SGI) to keep the OpenGL32.dll (for example) as standard upright (ie installing it automatically with drivers - or providing at least a simple installation pack), very much as it is done with OpenAL by now.
In my opinion not too much of a hassle - not more than having to install a new DirectX version or update for a new video game.

Would you sue Microsoft, because they provide no decent X-Windows system by default http://www.opengl.org/discussion_boards/ubb/smile.gif (or Linux, because Direct3D is not supported?).

dorbie

01-03-2004, 08:20 AM

EXT cannot come from a single vendor. It requires multiple vendors. A single vendor can use their own extension semantics for example SGI, ATI & NV. They all request the unique token enumeration space but what they do with it is their business. EXT extensions are different.

ARB was definitely introduced to help promote stuff to 'core', without mandating it, but it's use may have changed. When you consider the correct use of EXT extensions the ARB extension obviously conveys a more official status and is on the face of things redundant without that status.

[This message has been edited by dorbie (edited 01-03-2004).]

dorbie

01-03-2004, 08:38 AM

mw, MESA? WTF? Microsoft forced to implement drivers? Eh? We're talking about entry points in a stub library, not a driver implementation. The question is what to do in the absence of MS cooperation which is the current situation, not compelling them to do anything. Yep taking control of OpenGl32.dll would be nice, but you can't go around stomping all over windows components without Microsoft getting a tad upset about it, and they have a bit more say in the matter than us. They're happy to put OpenGL32.dll on hold, it's part of that whole monopoly thing. The "open" in OpenGL doesn't sit well with them now that they're the dominant platform.

FWIW everything is a hassle when you have hundreds of millions of users with problems running 3D apps & games. Just look at the consumer forums on opengl.org. It needs to be zero hastle and bullet proof and completely invisible, or darned close to it.

dorbie

01-03-2004, 08:58 AM

Jan2000, there are things SGI has done to improve the situation with OpenGL32.dll that you may never know about, they deserve more credit. They don't (or didn't) just sit on their ass, but companies change, the staff change and their business changes. Some people at SGI have done a heck of a lot more than most for OpenGL.

W.r.t. compelling MS or going it alone, I don't know if there would be a problem including a new dll with all graphics drivers (I mean a differently named one) especially those bundled with the OS or WHQL certified. I mean what's stopping IHV's getting off their duff and doing this? Do *they* give a darn? They should. Maybe there is a total roadblock.

[This message has been edited by dorbie (edited 01-03-2004).]

mw

01-03-2004, 09:07 AM

http://www.opengl.org/discussion_boards/ubb/smile.gif maybe I got that wrong. I read somewhere (ok, third hand rumors, but hey - this is an OT thread anyway) that Microsoft wanted to remove OpenGL support at all - and thought that it wouldn't be too bad, to install the entry point DLL to OpenGL manually (IE with a nice auto update at OpenGL.org, which would also provide a software implementation, if no hardware drivers are found).
Mesa could prove useful then, because OpenGL32 is not only a stub, but also a full OpenGL 1.1 software implementation(this is what I meant by "Microsoft writing new drivers" - which could be superseded by OpenGL 1.5 compliant Mesa drivers.

But the thought that Microsoft tries to put OpenGL on hold on Win32 systems, by keeping it in its current state by not removing it, is very interesting. It may even be true.

dorbie

01-03-2004, 09:23 AM

It's not a problem because you know what you're doing, joe public doesn't. Yes my original suggestion was that 3rd party apps which use it could install a dll as a redistributable.

My pref would be for IHVs to ship an ARB lib with all drivers but I dunno if they can, I assume they could do this, and perhaps even get it bundled with OS releases but driver certification gives Microsoft some control.

So you have an ARB lib that everyone ships & installs and provided nobody stuffs up the versioning it would just work.

OTOH you could just have a dev wrapper that everyone used that gave you the entry points by querrying the addresses. Anyone could write that today for developers only, and many developers have already. Heck if you look at the Quake source code Carmack was pretty much doing it years ago.

Jan

01-03-2004, 11:05 AM

Originally posted by dorbie:
OTOH you could just have a dev wrapper that everyone used that gave you the entry points by querrying the addresses. Anyone could write that today for developers only, and many developers have already.

Isnīt that what the "extension loading library" and GLEW do? As i said in my first post, using extensions is really not a problem, if you simply use one of those libraries. Therefore i donīt think we need a new dll. What advantages would such a dll give you ? I still didnīt get your point. If i check an ARB extension (and a library initializes it for me) or if i simply use it, because i have a dll where the entry points are stored does not make a difference to me.

And i never said, i wanted MS to be forced to update the dll. I simply meant, that if MS decides to stop OpenGL support someday, then SGI can go to court, just as Netscape did, because thatīs a misuse of their monopoly.

Simply said: As long as SGI cares for OpenGL on windows, there will be OpenGL on windows.

Jan.

mw

01-03-2004, 11:55 AM

Well, loading OpenGL entry points isn't that much of a problem, I agree. But Dorbie's proposal suggests more: if there were one standardized installation package, designed by Hardware vendors and SGI, you could include it with your application and call it automatically when starting your Setup program.
The OpenGL installation package would suggest and auto-update video drivers if needed (less hassle for video card manufacturers, better to support this than a lot of customers, who cannot even describe the problem in a meaningful manner) and make sure that the newest OpenGL implementation (dependent of the installed hardware and driver version) is installed.
The customer doesn't have to install a new video card driver, if he doesn't want to (but at least he doesn't have to search and install it by himself) - and an appropriate OpenGL.dll can be installed automatically if needed and everybody is happy: programmer, customer and hardware vendor (maybe even Microsoft, because everything works) http://www.opengl.org/discussion_boards/ubb/smile.gif .
One could even think of a downloadable "OpenGL installation CD" which contains Drivers for the most popular video cards, one could deliver with an application (since OpenGL is really backwards compatible, you know that newer driver versions will work...

dorbie

01-03-2004, 04:38 PM

SGI has done great things for OpenGL on windows in the past but to claim that they're the essential player in OpenGL on windows today and into the future is ludicrous, their stake and interest waned long ago. As for litigating over OpenGL32.dll updates, it's a silly discussion (IMHO).

[This message has been edited by dorbie (edited 01-03-2004).]

V-man

01-03-2004, 05:26 PM

The only reason to have an "updated dll" is to get rid of MS from the equation. The new dll can still be basic 1.1 compatible.

I said this a long time ago.

Is it possible? I dont know.
Isn't Creative the one who created EAX and EAX2? Arent those APIs for doing sound?
Correct me if my sources are wrong.

I tried to understand the workings of opengl32.dll a while ago and started writting my dll
I stoppped short and haven't picked it up.

If you guys are really motivated, go ahead and create it yourselves.

JanHH

01-03-2004, 07:19 PM

everybody go on and use linux!!

Jan

dorbie

01-03-2004, 08:22 PM

The only reason? What about fixing useage, the update itself is the main reason?

I have no idea if it's possible w.r.t. what can get through WHQL certification.

[This message has been edited by dorbie (edited 01-03-2004).]

mw

01-04-2004, 01:18 AM

Don't forget, that this is a "Santa Claus" thread http://www.opengl.org/discussion_boards/ubb/smile.gif

V-man

01-04-2004, 09:33 AM

What do you mean by fixing usage?

If you mean an openglARB.dll then it's certainly possible without getting anyone involved as long as openglARB.dll is dependent on opengl32.dll
Otherwise, we are talking about duplicating the ICD mechanism.

More importantly...
GL needs an official HLSL available everywhere.
Perhaps mccraighead was right. Maybe it should be implemented in a glu like library to releive pressure on driver developers.
Go ahead. Let it have version numbers.
(edit)Maybe have a flexible model. If a driver wants the HLSL the user wrote, the glu layer sends it, if driver wants something else like maybe bytecode, then glu can translate. Etcetera. (/edit)

I'm still coding in ARBvp,fp knowing these are dead end extensions.

[This message has been edited by V-man (edited 01-04-2004).]

dorbie

01-04-2004, 11:36 AM

That was what I was getting at with the fallback that the replacement library can simply wrap OpenGL32.dll on legacy cards & systems. It would be a step backwards to burden developers with juggling dlls.

For me the issue of HLSL is separate one, mccraighead is right from NVIDIA's point of view. Other vendors have a different one with 3Dlabs for example who's compiler technology is already an essential component with their lower level vp and fp their philosophy is that a duplicate compiler stack is a mess (others may share that view if the implement aggressive optimizations for assembly level vp and fp).

When you boil it down the separate vs integrated HLSL only matters when it comes to delivery. In reality either system can be developed separately. It's not necessarily a significant additional burden for driver developers when in fact it could and would be developed by a separate team.

Some have even suggested that a separate component that sits on drivers could present a bigger support problem w.r.t. versioning etc with some bugs & algorithms dependent on certain combinations of driver & HLSL. This is a far more obvious point than the driver burden thing.

Frankly I can see both sides of the debate.

Whichever way it's done, even if you had duplicated entry points I don't envisage this code existing more than once in a driver.

Korval

01-04-2004, 01:31 PM

It's not necessarily a significant additional burden for driver developers when in fact it could and would be developed by a separate team.

The resources come from the company. Either the company spends more money on GL support (hiring a new team), or that take resources away from driver development (make the driver team do it), or do a combination of both (hire a few new people, and siphon off of the current team).

dorbie

01-04-2004, 02:25 PM

Yep, that's a way of restating what I'm saying. The claim was that the external lib is less of a burden on driver developers than the internal one. That doesn't make a whole lot of sense to me. They each take equivalent effort and that should be staffed. Either COULD be developed by another team. Any problems would be self inflicted by management/orginisational structure.

The main issues boils down to delivery and support (plus and minus), and some of the delivery issues are not insurmountable, a driver doesn't have to be monolithic. But I don't have a dog in the hunt. I really don't care how it's done as long as it's done consistently by all. I'll just wait for the dust to settle and use what's there (like we have any other choice).

P.S. I do have opinions on this but they're nothing to do with driver burden etc. These are not really visible to applications developers IMHO. Although we benefit from good decisions. There are/were multiple issues on the table.

[snip]

[This message has been edited by dorbie (edited 01-04-2004).]

marcus256

01-07-2004, 04:52 AM

Regarding a new (ARB?) OpenGL.dll, I think it's a very good idea. It's what everybody would be expecting. It's how OpenGL works on every platform except for Windows, and how DirectX works, for instance. The hassle of keeping the user base up to date with recent driver/API versions is hardly a new issue in the PC community.

I also think it would be a good thing to get Microsoft out of the equation. However, we do need some kind of control (it shouldn't be left to the IHVs, for instance). ARB sounds like a natural pick.

Regarding the ICD mechanism: Doesn't the old SGI opengl.dll implementation have an ICD mechanism? I once wanted to use it as reference for software rendering performance, but ended up with performance almost on par with HW accelerated opengl32.dll. (?)

I don't know how hard it would to reimplement the ICD mechanism, but if it's doable (without any performance loss etc), my prefered solution would be ICD for HW acceleration and Mesa as a fallback solution (it has recent OpenGL functionality in software).

dorbie

01-07-2004, 09:03 AM

Right, but the IHVs need to be on board

I agree it has to be ARB controlled. It should work much the way the *inclusive* glext.h header file works right now IMHO, but it would not change as frequently and needs rigorous testing and beta testing before each release (and MUSN'T have vendor specific versions). The native (direct) bindings would be added to the common header each time the dll was released.

We probably also need some kludge to stop missing promoted exts or just go with lib versions.

V-man

01-07-2004, 09:49 AM

Originally posted by marcus256:
Regarding the ICD mechanism: Doesn't the old SGI opengl.dll implementation have an ICD mechanism? I once wanted to use it as reference for software rendering performance, but ended up with performance almost on par with HW accelerated opengl32.dll. (?)

That's correct, they know how it works.
I think they licensed it from MS.

The story is that MS licensed GL and did the minimum work to get the non-optimized SI running. In the process, they invented ICD (and MCD).

The software DLL was ****.
SGI did not like it, so they decided to create their own DLL.

So their goal was to improve GL on Windows.

And then, they say it's MS's job to support GL on their platform. They say they no longer have the right to develop any GL dll for MS.

dorbie

01-07-2004, 10:05 AM

OK a bit more info to convey the right impression.

The current OpenGL32.dll was last developed by SGI. They mirraculously got Microsoft to agree to accept their rev to version 1.3 and include the CosmoGL fastpath software optimizations SGI had previously used to embarras Microsoft's D3D FUD machine.

I'll leave it to your imagination to figure out how difficult this was at the end of the D3D vs OpenGL wars. It may very well be true that SGI can't develop any more bindings for Windows. In anycase why the heck should they, there are a couple of companies out there making $ millions off 3D graphics on Windows that have much more of a vested interest in OpenGL on Windows.

[This message has been edited by dorbie (edited 01-07-2004).]

marcus256

01-07-2004, 10:46 AM

Originally posted by dorbie:
Right, but the IHVs need to be on board

...yes, through the ARB (?).

and MUSN'T have vendor specific versions

That's what I meant.

3k0j

01-07-2004, 03:22 PM

I think some-body (ARB?) should "embrace & extend" the GLsetup...

there was small step (http://www.ati.com/companyinfo/press/2001/4408.html) in the right direction

dorbie

01-07-2004, 04:38 PM

GLSetup withered on the vine a long time ago. The developer stuff never got released and the site is gone. It was trying to solve a different problem (in some ways) since it concerned driver update and support when there were more players in the market and OpenGL was a bigger mess rather than simply updating the developer entry points.

dorbie

01-07-2004, 06:28 PM

P.S. I suppose it was closer than I give it credit. It is of course the runtime entry points that need to be distributed everywhere and hopefully supported by IHVs, incase that statement gave the wrong impression.

V-man

01-08-2004, 08:51 AM

Originally posted by dorbie:
The current OpenGL32.dll was last developed by SGI. They mirraculously got Microsoft to agree to accept their rev to version 1.3 and include the CosmoGL fastpath software optimizations SGI had previously used to embarras Microsoft's D3D FUD machine.
[This message has been edited by dorbie (edited 01-07-2004).]

Really? So you are saying the opengl32.dll that exists in Win95 is SGI's work?

I thought it was opengl.dll
MS had this habit of putting a 32 to distinguish between 16 bit dll

Yes, SGI is in contract with MS. During Farhenheit, they signed a contract so they gave up their right to develop any gl dll on any Windows platform, although SGI still holds information on the ICD.

Now, the thing to worry about is what will happen to GL on Longhorn.

dorbie

01-08-2004, 09:33 AM

Yes that lib was improved for 1.3 and had software performance enhancements of CosmoGL rolled into it by SGI, that's a fact, you can take it to the fact bank and cash it :-). It would never have happened if SGI hadn't tried damned hard to get it done and spend some of their leverage and resources to do it.

Neither you nor I know what's in SGI's contracts. It's very easy to stand on the sidelines and complain, but the facts is that the pradatory monopoly holds all the cards and frankly SGI's business & stock is in the toilet (relatively speaking). So excuse me for not joining you in holding their feet to the fire. SGI can be blamed for a many things but in this instance they did as much as they could & should, perhaps even more. The IHVs making money on OpenGL need to do something for themselves and their own freedom (and ours), they have always had the collective power to absolutely control the graphics interface on Windows. It was never SGI's call, they had almost no say, IHVs have always had the ability but never the collective guts or wisdom to do it. Or do you expect SGI to delve into it's deep pockets and do everyone another favor? :-)

Deiussum

01-08-2004, 10:10 AM

Originally posted by dorbie:
The current OpenGL32.dll was last developed by SGI. They mirraculously got Microsoft to agree to accept their rev to version 1.3 and include the CosmoGL fastpath software optimizations SGI had previously used to embarras Microsoft's D3D FUD machine.

I'm not saying your wrong here, but if this is true, whatever happened to this version of the DLL? The version that comes with XP still reports version 1.1 if you don't have a video card with proper driver support, or if you happen to pick a PIXELFORMATDESCRIPTOR that results in falling back to software mode.

dorbie

01-08-2004, 01:59 PM

I think the difference is in software implementation & acceleration of software contexts vs hardware contexts and available core function bindings instead of untyped extensions. You don't get a version string until you have a context active that is a very deliberate policy. But I'm getting an uneasy feeling about now. I wasn't involved in the work and don't want to overstate my case or dig a hole for myself. The whole thing was a sidebar about SGI's support for windows.

The point is SGI is for the most part a figurehead now w.r.t. windows activities. It owns the OpenGL trademark and has a vote on the ARB, but assuming that it controls OpenGL is a bit like saying Stallman controls Linux kernel development because he penned the GPL. SGI's influence stems from the expertise and cache of a few highly respected people who work those issues at SGI more than it's market share. It has a vote and a respected voice and not much more clout than that. It cannot simply steer some ARB.dll smoothly past everyone else and can't make anyone do anything. w.r.t. this issue it's one of the less relevant entities on the ARB although it has individuals who are some of the best suited to do the steering and have for example played important roles in collaborative efforts to fix & standardize the ABI on all Linux platforms. Where there's less unwelcome monopoly sabotage of the engineering.

I was just trying to supply a bit of context and set expectations and correct some historical points.

V-man

01-08-2004, 08:44 PM

By 1.3 you ment the third revision or implementation, right?

That info I gave comes from Mark Kilgard when he has at SGI and 1.2 was out and I wanted to know how long we had to use wglGetProcAddress.

The way I see it, there is 2 ways to be wanted, admired, utilized, be popular :

1. be open, invite participation, give out code, sell for almost nothing or give it away, and have no god like entity that controls the product.

2. have a big name, put out A+ product, have a long standing reputation, give away or sell expensive.

GL is in position 1, and it's good for it in the long run. MS is in position 2.

Why need source code? Just reverse engineer the DLL and if you have the DDK write your own DLL to load the ICD DLL. This will give you access to ICD accelerated PFDs only (which is what we all want). ;-)

Only problem is that one cannot distribute such a custom ICD loader for commercial use.