MS Longhorn ohne OGL ???

[Radeonator]

Nach diesen "News" (jaja nach 4 Tagen sinds keine News mehr ;) ) von heise.de Klick Mich (http://www.heise.de/newsticker/data/law-06.03.03-000/) scheint M$ seine Monopol Stellung auch auf Grafikprogrammier Schnittstellen ausdehnen. Was für Auswirkungen würde das haben (ausser das diverse OGL basierende Games nicht laufen würden...) und kann M$ sich das überhaupt leisten ???

[Demirug]

Deine Sorge bezüglich der OpenGL unterstüzung von Longhorn ist unbegründet. Die OpenGL Treiber kommen sowieso schon lange von den IHV. Die Software OpenGL Unterstützung ist AFAIK schon in XP nicht mehr enthalten weil es keinen Sinn mehr gemacht hat.

[zeckensack]

Die News bleiben ohne praktische Auswirkungen.
Microsoft pflegt die OPENGL32.DLL schon seit Jahren nicht mehr. Diese dient auch im wesentlich nur dazu, den Grafiktreiber mit dem Window manager zu verheiraten, und deswegen braucht sie die erweiterten Funktionen, die GL über die Jahre angesammelt hat auch nicht zu kennen.

Gebraucht wird diese Datei allerdings trotzdem (klick mich (http://www.opengl.org/discussion_boards/ubb/Forum7/HTML/000362.html)). Es wäre schon ein Problem, wenn MS sie nicht mehr ausliefern würde. Davon steht aber nichts bei Heise, und auch aus anderen Quellen war bisher nichts in der Richtung zu vernehmen :)

editOriginally posted by zeckensack:
"Pixel formats have nothing to do with Microsoft's implementation of OpenGL, they are used on ALL OpenGL implementations (on Windows at least, pfd's are not part of OpenGL but part of the GDI)"

The pixel format you choose on a display context is a modifier to the choice of GL implementation. The popular example is 16bit color + stencil on a Gf2MX or something. It does not even go through to NVIDIA's ICD, as is indicated by the renderer string. So it chooses the MS implementation. Based on pixel format. Now you could argue that you just would load NVOGL.DLL yourself and hope that it falls back to software itself. But ...

"nothing changes pixel format wise when you dynamically load OpenGL. You still go through the same procedure"

Please outline 'the same procedure'. You're aware that you'd somehow have to connect the GL implementation to the windowing system and all that crap. Everything that MS's OpenGL32.dll handles right now. It's not just DLL-Loading. And, as evidenced by comments from NVIDIA employees, right here on this board, the ICD isn't even designed to know about pfds.

The only exception is - tada - the 3dfx MiniGL because it just ignores the window system and pops up 16 bit fullscreen without bothering about anything. You don't want to make that common behaviour.

Yet more fun, you might have multiple monitors driven by totally different cards in your machine. Choice of ICD would depend on the window position. If it overlaps both monitors, it would fall back to software, otherwise it would chose the card the monitor is plugged into. Application programmers are simply in no position to choose an implementation, that's OS stuff.

I could pick up some more, but I'm not quite in the mood. In the end I think, if there were no OpenGL32.dll, as it is right now, someone would have to make one. I agree that the 'support' has been less than stellar, but it works, and every vendor making cards that run in Windows supports it.

[Demirug]

Dann zitiere ich auch mal ein bischen :)

Microsoft has the highest regard and respect for all the ARB members and will continue to work with individual members of the ARB, customers and ISVs (independent software vendors) who are developing applications that run on OpenGL to ensure that they will provide a great user experience under Windows.

und

Even though Microsoft will be focusing more energy on evolving Windows graphics, Microsoft sees OpenGL as an important component of the Windows Platform today and in the future.

[ActionNews]

Dazu passt folgendes: http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=3087970&forum_id=39208 :D!
Schade, dass es nur ein Fake ist :D! Wäre sicher interessant gewesen :D!

Ich wünschte mir mehr Hersteller würden wie ID Software auf OpenGL setzen! OpenGL scheint viel durchdachter zu sein! Ich programmiere nicht selber, aber habe schopn oft gehört, dass DirectX nicht gerade gut weiterentwicklet wurde und es einige Schlampereien gibt. OpenGL soll in der hinsicht viel besser sein ! In der Richtung hat sich John Carmack auch geäußert!

Wird Zeit, dass OpenGL 2 fertig wird :)! Wenn dann noch mehr Entwickler auf OpenGL+OpenAL/ML setzen würden wären Protierungen auf MacOSX und Linux ein Klacks!

CU ActionNews

[Demirug]

ActionNews, mal ganz ehrlich wenn es zu dieser Situation wirklich gekommen wäre was glaubst du wer nachgegeben hätte? Oder anders gefragt wer hätte mehr zu verlieren?

OpenGL ist nicht wirklich durchdachter nur anders. Für jemanden der noch nie etwas mit 3D APIs zu tun hatte ist OpenGL einfacher zu verstehen weil es dank des Immidiate Modes schnell zu Ergebnissen führt. Vergleicht man aber die Programmierung der wirklich performanten OpenGL verfahren (Immidiate Mode ist nicht wirklich schnell) mit D3D erkennt man sehr viele Ähnlichkeiten.

Das Gerücht (oder sagen wir mal die halbwahrheiten) mit der weiterentwicklung und der Schlamperei dabei kommt daher das MS bei D3D gerne mal die Verfahrensweise komplett umgeworfen hat. Seit DX7 ist aber nun eine gewiesse Kontinuität zu erkennen. Beim wechsel von DX8 zu DX9 musste nicht umlernen sondern nur dazulernen. Bei OpenGL war die Kontinuität von Anfang an besser was aber auch dazu führt das man zwangsläufig alle altlasten mitschlept.

Der Kommentar von JC zu DX stammt noch ganz aus den Anfangszeiten von D3D und damals war D3D wirklich sehr kompliziert zu verstehen. OpenGL war da die einfachere Alternative für alle die bei D3D kapituliert haben. Inzwischen hat sich JC Meinung im Bezug auf DX dahingehend geändert das er sich durchaus vorstellen könnte damit zu arbeiten er aber weiterhin OpenGL bevorzugt weil es im mehr Spielraum für Experimente mit neuen Grafikkartenfeatures gibt da die IHV einfach neue Extension einfügen können.

Zu OpenGL in der Spieleentwicklung sage ich einfach mal derzeit zu teuer und die kleinen Grafikkarten und Chip Hersteller (alle ausser NVIDIA und ATI) würde dabei schwere Nachteile haben und hätten kaum noch eine Möglichkeit in den Markt zu kommen.

[Desti]

Originally posted by zeckensack
[...] Es wäre schon ein Problem, wenn MS sie nicht mehr ausliefern würde. [...]


Könnte man dort nicht MESA als Ersatz nehmen?

[KingLouis]

kann ms mit longhorn und tcpa-fähiger nvidiakarte nicht einfach ogl sperren?

[robbitop]

was ist eigendlich mit OGL beschleunigtem Desktop??

sowas gibbet bei MAc schon lange und lässt sich viel smoother arbeiten..

[Bedman]

Hi unter Linux gibt es sowas auch siehe das auf den EVAS Libraries basierende Enlightenment .70 (Windows Manager/Desktop). Ist zwar zur Zeit noch in Entwicklung, aber die CVS Version läuft schon recht stabil. AntiAliasing, AlphaBlending und und und sind schon cool hardwarebeschleunigt;-)

Bedman

siehe www.enlightenment.org

[robbitop]

ich hatte gehofft, dass in Longhorn neben einem neuen endlich mal vernünftigem Dateisystem auch OGL beschleunigte Oberfläche dabei ist .. wenn beides nicht der Fall sein sollte, sehe ich keinen Grund für den Umstieg (okok das bunte zeuch is auch lustich)

[ActionNews]

Originally posted by Demirug
ActionNews, mal ganz ehrlich wenn es zu dieser Situation wirklich gekommen wäre was glaubst du wer nachgegeben hätte? Oder anders gefragt wer hätte mehr zu verlieren?

OpenGL ist nicht wirklich durchdachter nur anders. Für jemanden der noch nie etwas mit 3D APIs zu tun hatte ist OpenGL einfacher zu verstehen weil es dank des Immidiate Modes schnell zu Ergebnissen führt. Vergleicht man aber die Programmierung der wirklich performanten OpenGL verfahren (Immidiate Mode ist nicht wirklich schnell) mit D3D erkennt man sehr viele Ähnlichkeiten.

Das Gerücht (oder sagen wir mal die halbwahrheiten) mit der weiterentwicklung und der Schlamperei dabei kommt daher das MS bei D3D gerne mal die Verfahrensweise komplett umgeworfen hat. Seit DX7 ist aber nun eine gewiesse Kontinuität zu erkennen. Beim wechsel von DX8 zu DX9 musste nicht umlernen sondern nur dazulernen. Bei OpenGL war die Kontinuität von Anfang an besser was aber auch dazu führt das man zwangsläufig alle altlasten mitschlept.

Der Kommentar von JC zu DX stammt noch ganz aus den Anfangszeiten von D3D und damals war D3D wirklich sehr kompliziert zu verstehen. OpenGL war da die einfachere Alternative für alle die bei D3D kapituliert haben. Inzwischen hat sich JC Meinung im Bezug auf DX dahingehend geändert das er sich durchaus vorstellen könnte damit zu arbeiten er aber weiterhin OpenGL bevorzugt weil es im mehr Spielraum für Experimente mit neuen Grafikkartenfeatures gibt da die IHV einfach neue Extension einfügen können.

Zu OpenGL in der Spieleentwicklung sage ich einfach mal derzeit zu teuer und die kleinen Grafikkarten und Chip Hersteller (alle ausser NVIDIA und ATI) würde dabei schwere Nachteile haben und hätten kaum noch eine Möglichkeit in den Markt zu kommen.

Ich sag ja: Ich hätte es gehört. Selber programmiere ich ja nicht.

Aber warum ist OpenGL für Grafikchip-Entwickler teuer? Praktisch jeder Grafikchip bietet DirectX und OpenGL Support und was hat das mit Spielen zu tun? IMO ist es für die Spieleentwickler doch egal ob sie DirectX oder OpenGL nehmen. Naja OK! Bei den DX9-Features müsste man noch Herstellerextensions zurückgreifen, aber das sollte mit OpenGL 2 auch der Vergangenheit angehören. DX8-Features werden ja glaube ich von OpenGL 1.4 abgedeckt, oder nicht?

Ich finde da geht John Carmack echt mit gutem Beispiel voran, denn für ihn ist Protabilität wichtig!

Da hätte ich noch eine Frage: Warum setzen so viele Hersteller auf DirectX und nicht auf OpenGL? Welche Vorteile bringt das? Ich finde mit der Möglichkeit der Protabilität müsste doch OpenGL viel mehr Anklang finden.

CU ActionNews

[ActionNews]

Originally posted by robbitop
ich hatte gehofft, dass in Longhorn neben einem neuen endlich mal vernünftigem Dateisystem auch OGL beschleunigte Oberfläche dabei ist .. wenn beides nicht der Fall sein sollte, sehe ich keinen Grund für den Umstieg (okok das bunte zeuch is auch lustich)

So wie ich MS kenne, wird sowas wenn schon dann DirectX-beschleunigt :D!

CU ActionNews

[Exxtreme]

Originally posted by ActionNews

Da hätte ich noch eine Frage: Warum setzen so viele Hersteller auf DirectX und nicht auf OpenGL? Welche Vorteile bringt das? Ich finde mit der Möglichkeit der Protabilität müsste doch OpenGL viel mehr Anklang finden.

CU ActionNews
Bei DirectX hat man den Vorteil, daß man ein und der selbe Code auf jeder Grafikkarte läuft, die die gewünschten Features unterstützt. Bei OpenGL muss man Hersteller-Extensions nehmen und quasi für jeden Hersteller ein Extra-Süppchen kochen.

[Demirug]

Originally posted by ActionNews


So wie ich MS kenne, wird sowas wenn schon dann DirectX-beschleunigt :D!

CU ActionNews

Genau. Kommt mit Longhorn

[ActionNews]

Originally posted by Exxtreme

Bei DirectX hat man den Vorteil, daß man ein und der selbe Code auf jeder Grafikkarte läuft, die die gewünschten Features unterstützt. Bei OpenGL muss man Hersteller-Extensions nehmen und quasi für jeden Hersteller ein Extra-Süppchen kochen.

??? Ich dachte, das muss man nur, wenn die Funktionen noch nicht von OpenGL direkt unterstützt werden! Aber seit OpenGL 1.4 gibt es doch allgemeine Schnittstellen für "DX8-Funktionen", wie Shader usw., die für alle Grafikkarten-Hersteller gleich sein sollten. DX9-Features werden ja eh noch nicht genutzt.
Oder habe ich das falsch verstanden?
Auch eine Shader Hochsprache für OpenGL ist glaube ich geplant bzw in der Entwicklung, oder nicht?

CU ActionNews

[Exxtreme]

Originally posted by ActionNews


??? Ich dachte, das muss man nur, wenn die Funktionen noch nicht von OpenGL direkt unterstützt werden!
Schon, nur selbst OpenGL 1.4 hinkt der Technik ziemlich hinterher.


Originally posted by ActionNews
Oder habe ich das falsch verstanden?
Auch eine Shader Hochsprache für OpenGL ist glaube ich geplant bzw in der Entwicklung, oder nicht?

CU ActionNews
Tja, geplant ist es nur was noch nicht fertig ist, das kann man halt nicht nutzen.

[Demirug]

Originally posted by ActionNews


Ich sag ja: Ich hätte es gehört. Selber programmiere ich ja nicht.

Aber warum ist OpenGL für Grafikchip-Entwickler teuer? Praktisch jeder Grafikchip bietet DirectX und OpenGL Support und was hat das mit Spielen zu tun? IMO ist es für die Spieleentwickler doch egal ob sie DirectX oder OpenGL nehmen. Naja OK! Bei den DX9-Features müsste man noch Herstellerextensions zurückgreifen, aber das sollte mit OpenGL 2 auch der Vergangenheit angehören. DX8-Features werden ja glaube ich von OpenGL 1.4 abgedeckt, oder nicht?

Ich finde da geht John Carmack echt mit gutem Beispiel voran, denn für ihn ist Protabilität wichtig!

Da hätte ich noch eine Frage: Warum setzen so viele Hersteller auf DirectX und nicht auf OpenGL? Welche Vorteile bringt das? Ich finde mit der Möglichkeit der Protabilität müsste doch OpenGL viel mehr Anklang finden.

CU ActionNews

Ein Teil hat ja Exxtreme ja schon beantwortet.

OpenGL 1.4 normt bei weitem nicht den gleichen Umfang wie DX8. Gerade bei den per Pixel effekten muss man noch viel mit Hersteller extensions machen.

Protabilität? gut und schön. Erzähl das deinem Publischer und er lacht dich aus. Das Argument zählt nur wenn man es ohne Mehrkosten realisieren kann und das ist nicht drin.

Das grösste Problem bei OpenGL ist aber folgendes.

Stell dir vor es wurde gerade ein Spiel fertig gestellt welches auf allen derzeit erhältlichen Karten echt tolle Pixeleffekete hat und dann kommt einen Monat nach dem Realease einen neue Karte mit völlig anderen Extensions für die Pixelpipline auf den Markt. Was glaubst du wie die Käufer dieser Karte dann rumschreien?

[Demirug]

Die Shaderhochsprache GLslang kommt mit OpenGL 2.0.

[ActionNews]

Originally posted by Demirug


Ein Teil hat ja Exxtreme ja schon beantwortet.

OpenGL 1.4 normt bei weitem nicht den gleichen Umfang wie DX8. Gerade bei den per Pixel effekten muss man noch viel mit Hersteller extensions machen.

Protabilität? gut und schön. Erzähl das deinem Publischer und er lacht dich aus. Das Argument zählt nur wenn man es ohne Mehrkosten realisieren kann und das ist nicht drin.

Das grösste Problem bei OpenGL ist aber folgendes.

Stell dir vor es wurde gerade ein Spiel fertig gestellt welches auf allen derzeit erhältlichen Karten echt tolle Pixeleffekete hat und dann kommt einen Monat nach dem Realease einen neue Karte mit völlig anderen Extensions für die Pixelpipline auf den Markt. Was glaubst du wie die Käufer dieser Karte dann rumschreien?

Hmm...kann sein, aber bei ID Software klappt's doch auch :)! Was machen die Anders? Auch Epics UT2003-Engine läuft mit OpenGL und sogar unter Linux.

CU ActionNews

[Demirug]

Originally posted by ActionNews


Hmm...kann sein, aber bei ID Software klappt's doch auch :)! Was machen die Anders? Auch Epics UT2003-Engine läuft mit OpenGL und sogar unter Linux.

CU ActionNews

JC ist halt ein Exote und da ID die Engine ja immer fleisig lizenziert holt man sich die Mehrkosten so wieder rein.

Bei der Unreal Engine will ich mal sehen wie gut das noch funktioniert wenn mal jemand anfang die Shaderunterstüzung richtig zu nutzen. Dann sehe ich ehrlich gesagt etwas schwarz. Das Problem mit den Shadern haben aber alle Multiapi Engines.

[zeckensack]

Meine Bescheidene Meinung zum Thema:
DX Cap bits <=> OGL Extensions

Der Vorteil bei DX Graphics ist halt, daß jeder Hersteller eine 'Extension' auf die gleiche Weise unterstützt, respektive in der Summe viel weniger Extensions da sind.

Im Gegenzug kommt man bei OGL immer viel näher an die Fähigkeiten der Hardware heran. Wer die NV_register_combiners schonmal benutzt hat, der wird für 'texture blend stages' nurmehr ein müdes Lächeln übrig haben.

Das mit dem 'eigenes Süppchen kochen' muß auch nicht immer stimmen. Bei Hardware eines Fremdherstellers kann es schonmal vorkommen, daß 'fremde' Extensions auch dort unterstützt werden. 3DLabs' WildcatVP-Serie unterstützt zB die Shader-Extensions von NVIDIA. ATI unterstützt seit einiger Zeit NV_occlusion_query, etc.


Gerade im Bereich Pixel Shader halte ich dieses Extension-Argument sowieso für äußerst schwach. Wer rechtfertigen kann, seperate Shader für PS1.3, PS1.4, PS2.0, PS2.0+ und womöglich PS2.0++++++ oder was auch immer mitzuliefern, der kann ebensogut die Herstellerextensions unter OGL nutzen.
Im Zweifelsfall bekommt man auf diese Weise auch die besseren (=schnelleren) Shader heraus.

Btw soll Matrox' MTX_fragment_shader ATI_fragment_shader recht ähnlich sein. Und wenn SiS meint, Shadermäßig das gleiche zu können wie NV, dann können sie ruhig ebenso wie 3DLabs handeln. Dito für Trident. Wenn deren Pixel Shader das nicht schaffen, dann kann ich denen auch nicht helfen.

edit: ist => soll sein

[Demirug]

zeckensack, du hast die MTX_fragment_shader Beschreibung? Wo hast du den die aufgetrieben? Ich suche di schon eine ganze Zeit lang.

Ja die reg combiner sind nett aber glücklicherweise hat NVIDIA in den DX Treiber recht bissige optimierungscode eingebaut. Der Treiber bringt es zum Teil fertig 5 DX Stages in 2 regcombiner zu pressen.

In den Fällen wenn sich mehrer Hersteller auf eine Extension einigen keimt bei mir immer wieder Hoffnung auf um dann kurz darauf wieder zerstört zu werden.

Mir persönlich sind die unterschiedlichen Shaderversionen bei DX aber durchaus noch etwas lieber als die unterschiedlichen Extension bei OpenGL. Zumindestens das grundsätzliche Handling (Laden und aktivieren von Shadern, Setzten der Konstanten, Binden mit den Vertexinputs, ...) ist immer das gleiche. Nur der Shadercode als solches ändert sich und der gehört nicht zum Code sondern zum Content.

[Radeonator]

SiS Extensions und "mögliche" Extensions via Wrapper, biddösehr :

Here are the extensions :
4.13.1.2060
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_compiled_vertex_array
GL_EXT_packed_pixels
GL_EXT_polygon_offset
GL_EXT_separate_specular_color
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_object
GL_EXT_vertex_array
GL_WIN_swap_hint
GL_ARB_multitexture
GL_SGIS_multitexture
3.09.52
GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_transpose_matrix
GL_ARB_vertex_program
GL_ARB_window_pos
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_compiled_vertex_array
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_polygon_offset
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_swap_control
GL_EXT_texture3D
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_lod_bias
GL_EXT_texture_object
GL_EXT_vertex_array
GL_KTX_buffer_region
GL_SGIS_multitexture
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod
GL_SUN_multi_draw_arrays
GL_WIN_swap_hint
WGL_ARB_extensions_string
WGL_EXT_extensions_string
WGL_ARB_pixel_format
WGL_EXT_pixel_format
WGL_EXT_swap_control
WGL_ARB_extensions_string
WGL_ARB_pixel_format
WGL_EXT_extensions_string
WGL_EXT_pixel_format
WGL_EXT_swap_control
Latest 3.10.58 driver
GL_ARB_depth_texture
GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_shadow
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_transpose_matrix
GL_ARB_vertex_program
GL_ARB_window_pos
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_compiled_vertex_array
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_polygon_offset
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_shadow_funcs
GL_EXT_stencil_wrap
GL_EXT_swap_control
GL_EXT_texture3D
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_lod_bias
GL_EXT_texture_object
GL_EXT_vertex_array
GL_KTX_buffer_region
GL_NV_blend_square
GL_SGIS_multitexture
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod
GL_SGIX_depth_texture
GL_SGIX_shadow
GL_SUN_multi_draw_arrays
GL_WIN_swap_hint
WGL_ARB_extensions_string
WGL_EXT_extensions_string
WGL_ARB_pixel_format
WGL_EXT_pixel_format
WGL_EXT_swap_control
WGL_ARB_extensions_string
WGL_ARB_pixel_format
WGL_EXT_extensions_string
WGL_EXT_pixel_format
WGL_EXT_swap_control
It's good to see SiS updating their ICD and adding OpenGL extensions progressively.
As you can see, new OpenGL extensions were added in this new 3.10.58 driver if you compare it with the 3.09.52 : GL_ARB_depth_texture, GL_ARB_shadow, GL_EXT_shadow_funcs, GL_NV_blend_square (!!), GL_SGIX_depth_texture, GL_SGIX_shadow
The SiS 315 I have does not show unsupported extensions like fragment shader, etc. as it does not support those, so if any one could update this post with the Xabre extensions then it would be a nice gesture.
Well, I still prefer, for D3D, my old driver version 4.13.1.2060 which is very fast and overclockable from 166/166 to 178/180 mem and engine clock respectively.
I think that if SiS could add OpenGL S3TC implementation in software then it would be fun as I've got a software called Alieom for landscape generation. It requires HW based cube mapping, S3TC(s3 texture compression) etc.
Edit by xglider : The Xabre does support S3TC/DXTC texture compression.
There is also a software mesa opengl wrapper at http://www.mesa3d.org I found the extensions it supports and I've included them below, I hope no one minds.
The mesa Wrapper uses mesa 5. It supports 8 texture units instead of 2, Max Pixel Map Table is 65536 instead of 256, Projection Stack Depth is 32 instead of 6 in emulation. It kills my celeron 1.7/256MB/40GB/sis315e, but it did run the reflection demo meant for the Radeon 9000. Lol, I was hoping to make it run and I could.
Here are the extensions :
GL_ARB_depth_texture
GL_ARB_imaging
GL_ARB_multisample
GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_shadow
GL_ARB_shadow_ambient
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_transpose_matrix
GL_ARB_window_pos
GL_ATI_texture_mirror_once
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_logic_op
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_convolution
GL_EXT_compiled_vertex_array
GL_EXT_fog_coord
GL_EXT_histogram
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_paletted_texture
GL_EXT_point_parameters
GL_EXT_polygon_offset
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_shadow_funcs
GL_EXT_shared_texture_palette
GL_EXT_stencil_wrap
GL_EXT_stencil_two_side
GL_EXT_texture3D
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_object
GL_EXT_texture_lod_bias
GL_EXT_vertex_array
GL_HP_occlusion_test
GL_IBM_rasterpos_clip
GL_IBM_texture_mirrored_repeat
GL_INGR_blend_func_separate
GL_MESA_pack_invert
GL_MESA_resize_buffers
GL_MESA_ycbcr_texture
GL_MESA_window_pos
GL_NV_blend_square
GL_NV_point_sprite
GL_NV_texture_rectangle
GL_NV_texgen_reflection
GL_NV_vertex_program
GL_NV_vertex_program1_1
GL_SGI_color_matrix
GL_SGI_color_table
GL_SGIS_generate_mipmap
GL_SGIS_pixel_texture
GL_SGIS_texture_border_clamp
GL_SGIS_texture_edge_clamp
GL_SGIX_depth_texture
GL_SGIX_pixel_texture
GL_SGIX_shadow
GL_SGIX_shadow_ambien

[Desti]

Originally posted by Demirug
[...]
Stell dir vor es wurde gerade ein Spiel fertig gestellt welches auf allen derzeit erhältlichen Karten echt tolle Pixeleffekete hat und dann kommt einen Monat nach dem Realease einen neue Karte mit völlig anderen Extensions für die Pixelpipline auf den Markt. Was glaubst du wie die Käufer dieser Karte dann rumschreien?

Welchen Grund hätte der Grafikchiphersteller die Extensions inkompatibel zu machen?
Die wollen doch möglichst viele Chips verkaufen, also muss möglichst viel Software drauf laufen.

[Demirug]

Originally posted by Desti


Welchen Grund hätte der Grafikchiphersteller die Extensions inkompatibel zu machen?
Die wollen doch möglichst viele Chips verkaufen, also muss möglichst viel Software drauf laufen.

Die Hersteller machen das nicht wirklich mit Absicht. Da aber die Hersteller spezifischen Extensions in der Regel genau wiedergeben was ein Chip Featuremässig kann sind sie nicht immer ganz einfach von den Mitbewerbern übernehmbar. Die Alternative ist natürlich sich schon frühzeitig abzustimmen aber dann müsste man ja sehr früh die Karten auf den Tisch legen.

[Radeonator]

Originally posted by Desti


Welchen Grund hätte der Grafikchiphersteller die Extensions inkompatibel zu machen?
Die wollen doch möglichst viele Chips verkaufen, also muss möglichst viel Software drauf laufen.

Das liegt wohl eher an der Vorherrschaft zweier Hersteller.
Grundsätzliche kann man ja auch einen Renderpfad für alle schreiben, nur für "die Spezialitäten des hauses" werden die jeweiligen Hersteller spezifischen Extensions gebrauch. Meiner Meinung nach wäre ein klarer Standart natürlich viel logischer, da die HW dann an die SW angepasst werden müsste und nicht umgekehrt.

[zeckensack]

Originally posted by Demirug
zeckensack, du hast die MTX_fragment_shader Beschreibung? Wo hast du den die aufgetrieben? Ich suche di schon eine ganze Zeit lang.Nein, leider nicht. AFAIK ist die Spec noch immer nicht veröffentlicht, was böses verheißt.

Die Ähnlichkeit (wobei ich auch nicht weiß wie ähnlich das ist) leite ich von einem Kommentar eines Matrox-nahen, auf'm MURC, kurz nach dem Launch ab.

Da habe ich mich wohl ein wenig aus dem Fenster gelehnt. Ich werde das da oben mal ein wenig abschwächen :sulkoff:

[zeckensack]

Originally posted by Radeonator
As you can see, new OpenGL extensions were added in this new 3.10.58 driver if you compare it with the 3.09.52 : GL_ARB_depth_texture, GL_ARB_shadow, GL_EXT_shadow_funcs, GL_NV_blend_square (!!), GL_SGIX_depth_texture, GL_SGIX_shadow
NV_blend_square ist eine trivial-Extension und wird AFAIK von fast allen Karten unterstützt (Geforce 1+, ATI Radeon 1+, Matrox ???, Trident ???, i815+). Hat leider nichts mit Shadern zu tun. Es sieht so aus, als würde SiS unter OpenGL überhaupt keine Pixel Shader anbieten.
Die vertex_program-Extension ist btw sowieso Software-EMU, genau wie unter DX Graphics. Hier kann man also völlig unabhängig von den Hardware-Fähigkeiten agieren.

The SiS 315 I have does not show unsupported extensions like fragment shader, etc ...
Nochmal Frage: waren das die Extensions für den SiS315? Oder für Xabre I?

[Demirug]

Originally posted by zeckensack
Nein, leider nicht. AFAIK ist die Spec noch immer nicht veröffentlicht, was böses verheißt.

Die Ähnlichkeit (wobei ich auch nicht weiß wie ähnlich das ist) leite ich von einem Kommentar eines Matrox-nahen, auf'm MURC, kurz nach dem Launch ab.

Da habe ich mich wohl ein wenig aus dem Fenster gelehnt. Ich werde das da oben mal ein wenig abschwächen :sulkoff:

OK dann geht es dir wie mir. Gerüchte sagen aber das JC sie zum Beispiel bekommen haben soll.

[Demirug]

Originally posted by zeckensack
Nochmal Frage: waren das die Extensions für den SiS315? Oder für Xabre I?

Wenn ich den Xabre Treiber auseinander nehme finde ich das:


wglChoosePixelFormatEXT
wglGetPixelFormatAttribfvEXT
wglGetPixelFormatAttribivEXT
wglChoosePixelFormatARB
wglGetPixelFormatAttribfvARB
wglGetPixelFormatAttribivARB
wglFreeMemoryNV
wglAllocateMemoryNV
wglGetSwapIntervalEXT
wglSwapIntervalEXT
wglGetExtensionsStringEXT
wglGetExtensionsStringARB
glWindowPos3svARB
glWindowPos3ivARB
glWindowPos3fvARB
glWindowPos3dvARB
glWindowPos3sARB
glWindowPos3iARB
glWindowPos3fARB
glWindowPos3dARB
glWindowPos2svARB
glWindowPos2ivARB
glWindowPos2fvARB
glWindowPos2dvARB
glWindowPos2sARB
glWindowPos2iARB
glWindowPos2fARB
glWindowPos2dARB
glFogCoordPointerEXT
glFogCoorddvEXT
glFogCoorddEXT
glFogCoordfvEXT
glFogCoordfEXT
glSecondaryColorPointerEXT
glSecondaryColor3usvEXT
glSecondaryColor3usEXT
glSecondaryColor3uivEXT
glSecondaryColor3uiEXT
glSecondaryColor3ubvEXT
glSecondaryColor3ubEXT
glSecondaryColor3svEXT
glSecondaryColor3sEXT
glSecondaryColor3ivEXT
glSecondaryColor3iEXT
glSecondaryColor3fvEXT
glSecondaryColor3fEXT
glSecondaryColor3dvEXT
glSecondaryColor3dEXT
glSecondaryColor3bvEXT
glSecondaryColor3bEXT
glMultiDrawElementsEXT
glMultiDrawArraysEXT
glPointParameterfvARB
glPointParameterfARB
glIsProgramARB
glGetVertexAttribPointervARB
glGetVertexAttribivARB
glGetVertexAttribfvARB
glGetVertexAttribdvARB
glGetProgramStringARB
glGetProgramivARB
glGetProgramLocalParameterfvARB
glGetProgramLocalParameterdvARB
glGetProgramEnvParameterfvARB
glGetProgramEnvParameterdvARB
glProgramLocalParameter4fvARB
glProgramLocalParameter4fARB
glProgramLocalParameter4dvARB
glProgramLocalParameter4dARB
glProgramEnvParameter4fvARB
glProgramEnvParameter4fARB
glProgramEnvParameter4dvARB
glProgramEnvParameter4dARB
glGenProgramsARB
glDeleteProgramsARB
glBindProgramARB
glProgramStringARB
glDisableVertexAttribArrayARB
glEnableVertexAttribArrayARB
glVertexAttribPointerARB
glVertexAttrib4NuivARB
glVertexAttrib4NusvARB
glVertexAttrib4NubvARB
glVertexAttrib4NivARB
glVertexAttrib4NsvARB
glVertexAttrib4NbvARB
glVertexAttrib4dvARB
glVertexAttrib4fvARB
glVertexAttrib4uivARB
glVertexAttrib4usvARB
glVertexAttrib4ubvARB
glVertexAttrib4ivARB
glVertexAttrib4svARB
glVertexAttrib4bvARB
glVertexAttrib3dvARB
glVertexAttrib3fvARB
glVertexAttrib3svARB
glVertexAttrib2dvARB
glVertexAttrib2fvARB
glVertexAttrib2svARB
glVertexAttrib1dvARB
glVertexAttrib1fvARB
glVertexAttrib1svARB
glVertexAttrib4NubARB
glVertexAttrib4dARB
glVertexAttrib4fARB
glVertexAttrib4sARB
glVertexAttrib3dARB
glVertexAttrib3fARB
glVertexAttrib3sARB
glVertexAttrib2dARB
glVertexAttrib2fARB
glVertexAttrib2sARB
glVertexAttrib1dARB
glVertexAttrib1fARB
glVertexAttrib1sARB
glPolygonOffsetEXT
glPrioritizeTexturesEXT
glIsTextureEXT
glGenTexturesEXT
glDeleteTexturesEXT
glBindTextureEXT
glAreTexturesResidentEXT
glFlushVertexArrayRangeNV
glVertexArrayRangeNV
glDrawRangeElementArrayATI
glDrawElementArrayATI
glElementPointerATI
glGetVariantArrayObjectivATI
glGetVariantArrayObjectfvATI
glVariantArrayObjectATI
glGetArrayObjectivATI
glGetArrayObjectfvATI
glArrayObjectATI
glFreeObjectBufferATI
glDeleteObjectBufferATI
glGetObjectBufferivATI
glGetObjectBufferfvATI
glUpdateObjectBufferATI
glIsObjectBufferATI
glNewObjectBufferATI
glMultTransposeMatrixdARB
glMultTransposeMatrixfARB
glLoadTransposeMatrixdARB
glLoadTransposeMatrixfARB
glDrawRangeElements
glDrawRangeElementsEXT
glCopyTexSubImage3DEXT
glTexSubImage3DEXT
glTexImage3DEXT
glBlendEquationEXT
glBlendColorEXT
glGetCompressedTexImageARB
glCompressedTexSubImage3DARB
glCompressedTexSubImage2DARB
glCompressedTexSubImage1DARB
glCompressedTexImage3DARB
glCompressedTexImage2DARB
glCompressedTexImage1DARB
glBufferRegionEnabled
glDrawBufferRegion
glReadBufferRegion
glDeleteBufferRegion
glNewBufferRegion
glSelectTextureSGIS
glSelectTextureCoordSetSGIS
glMultiTexCoordPointerSGIS
glMultiTexCoord4svSGIS
glMultiTexCoord4sSGIS
glMultiTexCoord4ivSGIS
glMultiTexCoord4iSGIS
glMultiTexCoord4fvSGIS
glMultiTexCoord4fSGIS
glMultiTexCoord4dvSGIS
glMultiTexCoord4dSGIS
glMultiTexCoord3svSGIS
glMultiTexCoord3sSGIS
glMultiTexCoord3ivSGIS
glMultiTexCoord3iSGIS
glMultiTexCoord3fvSGIS
glMultiTexCoord3fSGIS
glMultiTexCoord3dvSGIS
glMultiTexCoord3dSGIS
glMultiTexCoord2svSGIS
glMultiTexCoord2sSGIS
glMultiTexCoord2ivSGIS
glMultiTexCoord2iSGIS
glMultiTexCoord2fvSGIS
glMultiTexCoord2fSGIS
glMultiTexCoord2dvSGIS
glMultiTexCoord2dSGIS
glMultiTexCoord1svSGIS
glMultiTexCoord1sSGIS
glMultiTexCoord1ivSGIS
glMultiTexCoord1iSGIS
glMultiTexCoord1fvSGIS
glMultiTexCoord1fSGIS
glMultiTexCoord1dvSGIS
glMultiTexCoord1dSGIS
glMTexCoord2fSGIS
glClientActiveTextureARB
glActiveTextureARB
glMultiTexCoord4svARB
glMultiTexCoord4sARB
glMultiTexCoord4ivARB
glMultiTexCoord4iARB
glMultiTexCoord4fvARB
glMultiTexCoord4fARB
glMultiTexCoord4dvARB
glMultiTexCoord4dARB
glMultiTexCoord3svARB
glMultiTexCoord3sARB
glMultiTexCoord3ivARB
glMultiTexCoord3iARB
glMultiTexCoord3fvARB
glMultiTexCoord3fARB
glMultiTexCoord3dvARB
glMultiTexCoord3dARB
glMultiTexCoord2svARB
glMultiTexCoord2sARB
glMultiTexCoord2ivARB
glMultiTexCoord2iARB
glMultiTexCoord2fvARB
glMultiTexCoord2fARB
glMultiTexCoord2dvARB
glMultiTexCoord2dARB
glMultiTexCoord1svARB
glMultiTexCoord1sARB
glMultiTexCoord1ivARB
glMultiTexCoord1iARB
glMultiTexCoord1fvARB
glMultiTexCoord1fARB
glMultiTexCoord1dvARB
glMultiTexCoord1dARB
glAddSwapHintRectWIN
glUnlockArraysEXT
glLockArraysEXT
glGetColorTableParameterivEXT
glGetColorTableParameterfvEXT
glGetColorTableEXT
glCopyColorTableEXT
glColorTableEXT
glColorSubTableEXT
glGetPointervEXT
glEdgeFlagPointerEXT
glTexCoordPointerEXT
glIndexPointerEXT
glColorPointerEXT
glNormalPointerEXT
glVertexPointerEXT
glDrawArraysEXT
glArrayElementEXT


Überleg dir was du damit machst :D

PS: In dem Treiber gibt es auch noch eine Liste mit Namen von Spielen und Benchmarks.

[Xmas]

Lustigerweise sagt die Liste gar nichts über ARB_fragment_program aus, da ARB_vertex_program genau dieselben (plus ein paar weitere) Funktionen verwendet. Außerdem gibt es einige Extensions, die ledigich neue Token und keine Funktionen definieren.

[Desti]

Originally posted by Xmas
Lustigerweise sagt die Liste gar nichts über ARB_fragment_program aus, da ARB_vertex_program genau dieselben (plus ein paar weitere) Funktionen verwendet. Außerdem gibt es einige Extensions, die ledigich neue Token und keine Funktionen definieren.


Was ist denn ein 'Token' ? *nixblick*

[aths]

Originally posted by Demirug
Die Hersteller machen das nicht wirklich mit Absicht. Da aber die Hersteller spezifischen Extensions in der Regel genau wiedergeben was ein Chip Featuremässig kann sind sie nicht immer ganz einfach von den Mitbewerbern übernehmbar. Die Alternative ist natürlich sich schon frühzeitig abzustimmen aber dann müsste man ja sehr früh die Karten auf den Tisch legen. Imo ist jede Radeon und jede GeForce in gewissen Grenzen Register Combiner kompatibel. Schade dass es da keine nachträgliche von beiden Marktführern unterstützte Extension gibt, die per pixel shading möglich macht.

[Demirug]

Originally posted by Xmas
Lustigerweise sagt die Liste gar nichts über ARB_fragment_program aus, da ARB_vertex_program genau dieselben (plus ein paar weitere) Funktionen verwendet. Außerdem gibt es einige Extensions, die ledigich neue Token und keine Funktionen definieren.

Hast recht das war die falsche Liste :D

Das müsste die richtige sein


GL_ARB_depth_texture
GL_ARB_multitexture
GL_ARB_imaging
GL_ARB_point_parameters
GL_ARB_shadow
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_transpose_matrix
GL_ARB_vertex_program
GL_ARB_window_pos
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_compiled_vertex_array
GL_EXT_cull_vertex
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_paletted_texture
GL_EXT_polygon_offset
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_shadow_funcs
GL_EXT_stencil_wrap
GL_EXT_swap_control
GL_EXT_texture3D
GL_EXT_texture_compression_s3tc
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_lod_bias
GL_EXT_texture_object
GL_EXT_vertex_array
GL_ATI_element_array
GL_ATI_vertex_array_object
GL_KTX_buffer_region
GL_NV_blend_square
GL_NV_vertex_array_range
GL_S3_s3tc
GL_SGIS_generate_mipmap
GL_SGIS_multitexture
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod
GL_SGIX_depth_texture
GL_SGIX_shadow
GL_SUN_multi_draw_arrays
GL_WIN_swap_hint
WGL_ARB_extensions_string
WGL_EXT_extensions_string
WGL_ARB_pixel_format
WGL_EXT_pixel_format
WGL_EXT_swap_control


Wenn nicht irgendwo noch was versteckt ist sollte es das gewesen sein.

[Xmas]

Originally posted by Desti
Was ist denn ein 'Token' ? *nixblick*
Token = in diesem Fall eine Konstante die man für Funktionsaufrufe verwendet (z.B. GL_MATRIX0_ARB)

[zeckensack]

Originally posted by Demirug


Hast recht das war die falsche Liste :D

Das müsste die richtige sein

<snip>Aha! =)
SiS unterstützt also sowohl NV_vertex_array_range, als auch ATI_vertex_array_object (plus Anhang). Das ist sehr löblich und verheißt in diesem Punkt maximale Kompatibilität zu den beiden 'großen' :)

Falls unklar, @Kopfkratzer,
das sind die Extensions zum flotten Transfer von Geometriedaten. Demnächst soll die ATI-Version (leicht modifiziert) zu ARB_vertex_array_object erhoben werden, dann ist dieses Problem auch komplett vom Tisch.

[Xmas]

Ich hab mal die NTFS-Diskussion gesplittet:
http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=59590

[AlfredENeumann]

Originally posted by Demirug


Genau. Kommt mit Longhorn

Da freuen sich die besitzer einer GFFX 5800 ultra.
Da wird wohl ein Patch im Treiber notwendig.

[Lorien]

Hehe ja dann ist nix mehr mit stille wenn man sich nur aufm Desktop befindet.

[Demirug]

Originally posted by Lorien
Hehe ja dann ist nix mehr mit stille wenn man sich nur aufm Desktop befindet.

Für Longhron werden wohl sowieso neue Treiber fällig und die muss man dann eben so bauen das die Karten im Desktop Betrieb nicht auf den 500/500 Hochfahren sondern schön bei 300/300 bleiben.

[Desti]

Originally posted by Demirug


Für Longhron werden wohl sowieso neue Treiber fällig und die muss man dann eben so bauen das die Karten im Desktop Betrieb nicht auf den 500/500 Hochfahren sondern schön bei 300/300 bleiben.

Dann ruckelt der Desktop :D

[Demirug]

Originally posted by Desti


Dann ruckelt der Desktop :D

Eher nicht. Im wesentlichen werden da nur ein paar Vierecke (pro offenem Fenster auf dem Desktop eine) mit SingleTexturing gerendert. Die Anforderungen an die Geometrieleistung sind gleich null. Der Fillratebedarf hängt im wesentlichen von der Anzahl und grösse der Fenster ab. Aber selbst bei nur 300 MHz ist da genügend Fillrate vorhanden.

[JaDz]

Also keine PS2.0-Hintergrundbilder, 16xAF Startleisten oder 8xAA-Icons???;D :rofl:

[Spake]

der grafikkartenmarkt wird mit lonhorn wieder aufblühen weil die ganzen DAU sich die achso tollen/schnellen grafikkarten holen müssen :D

mal erlich was ich von longhorn gesehen hab ist nett wirklich dx8> bedürftig