Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

OpenGL SC

Name: Anonymous 2011-07-25 18:29

It's the only OpenGL you'll need.

Name: Anonymous 2011-07-25 21:32

But you cant do color cycling in OpenGL!

Name: Anonymous 2011-07-25 22:12

>>2
Shaders + dependent texture lookups nigger.

Name: Anonymous 2011-07-25 22:32

>>3
Shaders are slow and you cant do them on cell phones.

Name: Anonymous 2011-07-25 22:35

OpenGL cant even paint player's units into his color. How can you discern your zergs from enemy ones?

Name: Anonymous 2011-07-25 22:53

>>4
>Shaders are slow
as opposed to what?!

Name: Anonymous 2011-07-25 22:58

>>6
Software rendering.

Name: Anonymous 2011-07-25 23:12

>>7
wait.

wait.

so what you're saying is that...
that...
it is faster to render graphics using software than hardware?

This is what you're saying?

Name: Anonymous 2011-07-25 23:15

>>8
It takes time to:
- learn OpenGL and mathematical analysis, required to operate OpenGL
- earn enough money to buy a highend PC, supporting shaders

Name: Anonymous 2011-07-25 23:18

Also, software rendering is portable.

Name: Anonymous 2011-07-25 23:23

if you don't have a video card that can support a decent shader model then you are a faggot.

Name: Anonymous 2011-07-25 23:28

>>11
I use OLPC XO-1.

Name: Anonymous 2011-07-26 3:23

Thiouracil Rachel Crosby palladium uptown Aida decent stomp. Boltzmann cotangent acetone Tektronix align. Inalienable.

Name: Anonymous 2011-07-26 3:26

>>8
Saloon Thomson shoemake iodinate allegory lemma coattail immune beefy ton... Ineducable propellant amphibology... Trickle housefly via.

Name: Anonymous 2011-07-26 3:31

Blueberry expulsion jurisprudential fiasco watercourse agave. Sole. Precaution recipient swat...

Name: Anonymous 2011-07-26 3:35

Calcify forgery Kennecott psychosomatic giblet. Benton archfool muslim irreconcilable. Concord found administratrix else scotch buzzy Ella Luftwaffe reck.

Name: Anonymous 2011-07-26 3:40

Woody. Motor cogitate... Projectile diminish hydrochemistry Belshazzar systemwide...

Name: Anonymous 2011-07-26 4:10

yeah safety critical!

Name: Anonymous 2011-07-26 5:14

>>7
Shaders are slower than software rendering? Are you brain dead?

Shaders are software. They allow you to program a part of the rendering pipeline. They usually use a restricted subset of C with some additional extensions.

Compute kernels have evolved from shaders, and provide a much richer subset of general purpose programming languages. Compute kernels are usually C or C++ based depending on what technology you're using.

Shaders and compute kernels are software designed to run in parallel on heterogenous computing devices like GPUs.

The only reason software rendering is making a return is because heterogenous computing languages like OpenCL/DirectCompute/C++ AMP are making GPGPU programming much more accessible and familiar feeling. That's right. The future of software rendering still won't be done on traditional, out-of-order, cache-coherent general purpose CPUs. It's being done on heterogeneous devices--GPUS--and with new languages designed for extreme levels of parallelization. And no, things like Go, Scala, Haskell or even Clojure are not designed for extreme levels of parallelization, they're just some experiment that ventured part way into parallel computing and ended up with a half-baked result.

I won't classify CUDA in the same league as the aforementioned languages, mainly because it's shit and still doesn't implement half the features in DirectCompute or OpenCL 1.1. nVidia still hasn't released full OpenCL 1.1 drivers yet either. Fuck nVidia and their proprietary bullshit.

Name: Anonymous 2011-07-26 6:21

>>4
Your cellphone sucks. Get a better one, like an iPhone 4.

Name: Anonymous 2011-07-26 7:44

>>19
Can't you use the Nouveau driver to do OpenCL 1.1?

Name: Anonymous 2011-07-26 9:00

>>20
hipster shit

Name: Anonymous 2011-07-26 10:03

>>22
Even I know YHBT

Name: Anonymous 2011-07-26 10:24

>>1
Deprecating the FF-P and Display Lists was a terrible decision of the ARB, because:
* The FF-P almost always provide better performance than the shader programs you'd use, as the drivers vendors include OPTIMIZED VROOM VROOM! emulation shaders.
* Geometry-only Display Lists are implemented using tachyons on nVidia and always beat STATIC_DRAW VBO in speed.

It was a stupid attempt at mimicking Direct3D instead of making the good features of GL easier to use and extending the FF-P.

Name: Anonymous 2011-07-26 10:49

>>24
who cares about nvidia, they don't supply proper documentation for their hardware

Name: Anonymous 2011-07-26 11:03

>>21
Correct, neither the Nouveau nor open-source AMD/ATI driver support OpenCL in any way. nVidia provides OpenCL 1.0 support in their binary blob driver, and AMD and Intel both provide OpenCL 1.1 support in their binary drivers.

As far as I know, there is currently no working open-source OpenCL implementations. It wouldn't be hard to put one together for AMD/ATI cards given that AMD publishes all of the low-level details, registers and memory-mapped I/O stuff. It'd be more tricky for Nouveau as you'd have to reverse engineer the binary blob drivers.

Name: Anonymous 2011-07-26 11:11

>>24
Display lists were deprecated for good reason, as they don't explicitly support parallelism and they contain too much state capturing bloat which is redundant for programmable pipelines.

OpenGL 4.2 or 5.0 or whatever they decide to call it, that is, the next upcoming revision to OpenGL, will contain a full-blooded modern replacement for display lists that will support parallelism: you will be able to construct draw call lists across multiple threads. Direct3D11 has supported this since 2009 with multi-threaded deferred render contexts.

Also, the FF-P was shit, get over it. It had a lot of call-overhead and had shitty fine-grained state management which limited overall throughput. It's fucking trivial to write just as optimized emulation shaders. If you can't do that, you suck. Even John Carmack, a long-time OpenGL advocate, came out last year and declared that Direct3D had been better than OpenGL since Direct3D9, for largely these reasons.

Name: Anonymous 2011-07-26 11:40

>>27
OpenGL 4.2 or 5.0 or whatever they decide to call it, that is, the next upcoming revision to OpenGL, will contain a full-blooded modern replacement for display lists that will support parallelism: you will be able to construct draw call lists across multiple threads. Direct3D11 has supported this since 2009 with multi-threaded deferred render contexts.
I agree that Display Lists are bloated overkill, but why did they deprecate them before introducing a replacement for static geometry?

Also, the FF-P was shit, get over it. It had a lot of call-overhead and had shitty fine-grained state management which limited overall throughput. It's fucking trivial to write just as optimized emulation shaders. If you can't do that, you suck. Even John Carmack, a long-time OpenGL advocate, came out last year and declared that Direct3D had been better than OpenGL since Direct3D9, for largely these reasons.
If a new pipeline stage gets integrated in the graphics hardware, programs using a future-proof FF-P can take advantage of it without needing an update. We've seen that before with hardware T&L. Of course, OpenGL's FF-P isn't future-proof anymore.
Also, I compared the performance of FF-P vs. shaders (GLSL) with orthogonal textured quads on an old R300 with the free radeon driver, and the FF-P gave me a few more FPS. Perhaps the Gallium3D shader compiler sucks and I gotta try assembly.

Name: Anonymous 2011-07-26 13:52

>>19
Non-portable proprietary drivers shit.

Name: Anonymous 2011-07-27 0:47

>>28
Gallium3D
There's your problem. The design of the OpenGL programmable pipeline interfaces and GLSL is sound. Gallium3D was an abstraction layer and it has to translate calls to the native graphics APIs. For FF-P, it just delegates calls to the underlying graphics layer, for programmable stuff, it has to translate GLSL and do so much shit which has overhead.

Gallium3D is a dead project anyway, it got merged into the Mesa3D mainline.

GLSL through native GL layers like Mesa3D or binary-blob drivers doesn't suffer from these problems. If you're using an old R300, you should probably migrate to the newer open-source AMD drivers which are included with newer versions of X.org and/or Wayland.

AMD/ATI is no longer an enemy of your freedom.

http://www.x.org/wiki/RadeonFeature

Name: Anonymous 2011-07-27 0:56

>>28
I agree that Display Lists are bloated overkill, but why did they deprecate them before introducing a replacement for static geometry?
They were merely deprecated, display lists are still available for use. Deprecating them without providing an alternative is fine. If they had made them obsolete and completely removed them from the spec, that would have been a different story.

Expect a bunch of old GL features to be completely removed in the future, once the newer features have taken hold for a few iterations.

Name: Anonymous 2011-07-27 1:22

It should be mentioned that the FF-P has the advantage of providing very simple and easy-to-use modular functionality. If you want that using the programmable pipeline, you have to implement some kind of meta-programming facilities to combine various GLSL fragments in rather complex ways.

Not saying that the programmable pipeline isn't better and that the FF-P shouldn't at least be provided by some external library if at all. Just saying'.

Name: Anonymous 2011-07-27 1:23

>>31
Expect a bunch of old GL features to be completely removed in the future
That is why software rendering owns OpenGL. For example, 3.0 dropped support for Texture Combiners and you can't run your legacy stuff anymore.

Name: Anonymous 2011-07-27 1:45

>>33
I don't think feature deprecation is a reason not to use OpenGL or other 3D specific APIs. The old methods aren't always the best, and the fixed-function pipeline is pretty stupid.

I think OpenGL and Direct3D are nearing a point where you won't see much additions of new features, and as a result you'll see people migrating back to software rendering.

But most current software renderers are useless and thus obsolete moving forward because they aren't written to take advantage of massively parallel heterogeneous computing devices. They're usually hard coded for a specific CPU architecture with optimized SIMD assembly functions.

As I've already said, the future of software rendering is on GPUs and FPGAs. AMD's new Fusion System Architecture, for example, which they've made openly licensable (Intel and ARM Holdings have adopted it) and CPU/GPU agnostic, merges the memory model between CPUs and GPUs/FPGAs, provides ISA virtualization, and new dedicated DMA channels across all computing resources. And the best way to start taking advantage of this stuff is to use OpenCL or DirectCompute.

Name: Anonymous 2011-07-27 1:49

>>34
I don't think feature deprecation is a reason not to use OpenGL or other 3D specific APIs.
I downloaded your minecraft video game. It refuses to run, saing something about opengl.dll symbol not found. What should I do?

I'm trying to compile Quake 3, but GCC chokes on a bunch of nonsense opengl.h errors

Name: Anonymous 2011-07-27 1:52

>>35
What should I do?
Re-install Windows. Run registry cleaner and memory optimizer.

Name: Anonymous 2011-07-27 1:54

>>35
On Windows, you don't use opengl.h. You use glew.h. opengl.h only provides OpenGL 1.1 conformance.

http://en.wikipedia.org/wiki/OpenGL_Extension_Wrangler_Library

Also, hardware vendors will most likely support older OpenGL versions in their drivers going forward for some time. You can support multiple GL versions side-by-side no problem.

Name: Anonymous 2011-07-27 2:05

>>37
Also, hardware vendors will most likely support older OpenGL versions in their drivers going forward for some time.
You see, one has a choose: either writing portable code, that will work forever, or writing OpenGL code, that will be deprecated after next year. If one writes some simple DOSBox-like utility, using software-rendering will remove 95% of inconvenience and graphic bugs.

Name: Anonymous 2011-07-27 2:09

>>38
CPU software rendering is too slow.

Name: Anonymous 2011-07-27 2:11

>>39
"too slow" for what?

Name: Anonymous 2011-07-27 2:24

>>39
Thats only without UNLIMITED DETAIL PROCESSING

Name: Anonymous 2011-07-27 2:40

>>40
Too slow for 3D graphics with sufficient detail. You might be able to do Quake 3 quality graphics on a 4-core CPU these days. But you won't be doing Crysis, Metro 2033, Rage, or Battlefield 3 quality graphics. You'll need a thousand+ many-core vector processor, which is what GPUs essentialy are.

>>41
UNLIMITED DETAIL PROCESSING
It's fake shit. There's no such thing as unlimited detail processing. He's a con-artist looking for gullible investors.

Name: Anonymous 2011-07-27 3:11

>>42
DOSBox doesn't need 3D graphics.

Name: Anonymous 2011-07-27 3:14

>>43
That's because you've never played Wolfenstein 3D

Name: Anonymous 2011-07-27 3:16

>>44
Only few DOS games require OpenGL. And they use it's old version, called Glide. It's easier to emulate Glide, than translate to OpenGL.

Name: Anonymous 2011-07-27 3:30

>>42
FrozenVoid is not a con-artist looking for gullible investors.  He is just an autistic high-schooler who doesn't know anything.

Name: Anonymous 2011-07-27 6:43

>>45
Glide has nothing to do with OpenGL. They're completely different APIs. Glide was 3Dfx's proprietary API, similar to how nVidia is pushing it's proprietary CUDA shit these days.

OpenGL was completely different and had it's origins at Silicon Graphics.

Name: Anonymous 2011-07-27 15:04

>>47
http://en.wikipedia.org/wiki/Glide_API
Glide is based on the basic geometry and "world view" of OpenGL. OpenGL is a large graphics library with 336 calls[citation needed] in the API, many of which are of limited use. Glide was an effort to select primarily features that were useful for real-time rendering of 3D games.
i.e. it's a stripped down GL.

Name: Anonymous 2011-07-27 15:06

>>48
Also
The name Glide was chosen to be indicative of the GL underpinnings, while being different enough to avoid trademark problems.

Name: Anonymous 2011-07-27 15:19

>>48-49
Anyway, Glide isn't an ``old version called Glide''.

Name: Anonymous 2011-07-27 15:49

>>50
It was the standard GL implementation for some time.

Name: Anonymous 2011-07-27 16:13

>>51
Shut up instead of posting erroneous information.

Name: Anonymous 2011-07-27 16:57

>>52
Wikipedia is "erroneuous"?

Name: Anonymous 2011-07-27 16:58

>>53
Is that a trick question?

Name: Anonymous 2011-07-27 17:07

>>54
Why do you ask?

Name: Anonymous 2011-07-28 0:35

>>48
No it's not, that wiki article is wrong. I've used Glide before back in the late 90s. It's a completely different API, there's nothing at all like OpenGL in there.

Name: Anonymous 2011-07-28 4:24

>>56
lol wikipedia quality!

Name: Anonymous 2011-07-28 5:28

Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -