Poll

Which is more important to you for OpenGL?

High precision rendering
4 (19%)
Sacrificing precision for render speed
6 (28.6%)
A balance between the two (IF possible)
11 (52.4%)

Total Members Voted: 0

Author Topic: OpenGL ddk  (Read 69072 times)

warpcafe

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 746
  • Failure is not an option.
    • View Profile
Re: OpenGL ddk
« Reply #120 on: 2011.01.28, 11:02:49 »
Dee,

I have to admit that when asked "precision or speed" I'd say "it depends" :)
The point for me here is that I basically have no idea what the GL/2 will be "used for" - is it rather "gaming" or "everything"?

If we talk about rendering of "everything" (including typefaces/fonts, applications screen output in general a la OpenOffice...) then I'd vote for "precision". However, if GL/2 will rather be used for "gaming" then I'd say "speed". Well, honestly, I'd say "I don't care" since I don't do any such games that would require intensive 3D stuff. ;)

Perhaps you can give some more details for n00bs like me what GL/2 will be used for?
(Sorry if everyone else here understands...)

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #121 on: 2011.01.28, 14:09:14 »
Well,
would not it be possible to have BOTH - precision AND speed - as selectable driver configurations?

Here's the deal. The OpenGL spec gives the lowest level of precision that's acceptable for certain datatypes, but allows you to over-achieve on things a bit. For instance, a particular value may be allowed to be represented as a float (32-bit floating point), but that's just the low end, you're more than free to represent that value as a double (64-bt floating point). Obviously, the double has more precision, but it's also a slight bit slower to work with. Also, there are many OpenGL functions that are all basically the same with the only differences being the size of the datatypes accepted and whether or not the arguments come in an array or are explicitly spelled out. I'm not going to sit here & implement separate versions of these functions. Instead, I'm going to do the smart thing, the part of the GL context that the function modifies will be in only 1 precision. All of the various functions that modify that particular variable will have to convert their data to the correct datasize & then call another function that does the actual modification.

Ex.:

GLAPI void GLAPIENTRY glVertex2d( GLdouble x, GLdouble y );
GLAPI void GLAPIENTRY glVertex2f( GLfloat x, GLfloat y );
GLAPI void GLAPIENTRY glVertex2i( GLint x, GLint y );
GLAPI void GLAPIENTRY glVertex2s( GLshort x, GLshort y );

GLAPI void GLAPIENTRY glVertex3d( GLdouble x, GLdouble y, GLdouble z );
GLAPI void GLAPIENTRY glVertex3f( GLfloat x, GLfloat y, GLfloat z );
GLAPI void GLAPIENTRY glVertex3i( GLint x, GLint y, GLint z );
GLAPI void GLAPIENTRY glVertex3s( GLshort x, GLshort y, GLshort z );

GLAPI void GLAPIENTRY glVertex4d( GLdouble x, GLdouble y, GLdouble z, GLdouble w );
GLAPI void GLAPIENTRY glVertex4f( GLfloat x, GLfloat y, GLfloat z, GLfloat w );
GLAPI void GLAPIENTRY glVertex4i( GLint x, GLint y, GLint z, GLint w );
GLAPI void GLAPIENTRY glVertex4s( GLshort x, GLshort y, GLshort z, GLshort w );

GLAPI void GLAPIENTRY glVertex2dv( const GLdouble *v );
GLAPI void GLAPIENTRY glVertex2fv( const GLfloat *v );
GLAPI void GLAPIENTRY glVertex2iv( const GLint *v );
GLAPI void GLAPIENTRY glVertex2sv( const GLshort *v );

GLAPI void GLAPIENTRY glVertex3dv( const GLdouble *v );
GLAPI void GLAPIENTRY glVertex3fv( const GLfloat *v );
GLAPI void GLAPIENTRY glVertex3iv( const GLint *v );
GLAPI void GLAPIENTRY glVertex3sv( const GLshort *v );

GLAPI void GLAPIENTRY glVertex4dv( const GLdouble *v );
GLAPI void GLAPIENTRY glVertex4fv( const GLfloat *v );
GLAPI void GLAPIENTRY glVertex4iv( const GLint *v );
GLAPI void GLAPIENTRY glVertex4sv( const GLshort *v );

All of these functions create a vertex (4-dimensional point). The differences are how many planes of space are used to represent the vertex, how the data is passed to the function, & the precision of the data. Obviously, I wouldn't want to represent the vertex as a short (16-bit integer); however, representing it as an int verses a float or double may give certain speed advantages on older CPU's & GPU's. On modern hardware, it may not be as big of an issue & there'd really be no reason to not go with a float or a double. Who knows, the future may bring code that decides which to use based on which CPU the host system has, but for now, I need to get something running & I thought it might be prudent to solicit outside opinions. Also, I've already decided to go ahead & represent all vertices in terms of (x, y, z, w) internally, regardless of how many values are passed to the glVertex function. Non-specified values will probably be represented as 0 for the basic 3d coordinates & 1 for the w component.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #122 on: 2011.01.28, 14:14:26 »
Dee,

I have to admit that when asked "precision or speed" I'd say "it depends" :)
The point for me here is that I basically have no idea what the GL/2 will be "used for" - is it rather "gaming" or "everything"?

If we talk about rendering of "everything" (including typefaces/fonts, applications screen output in general a la OpenOffice...) then I'd vote for "precision". However, if GL/2 will rather be used for "gaming" then I'd say "speed". Well, honestly, I'd say "I don't care" since I don't do any such games that would require intensive 3D stuff. ;)

Perhaps you can give some more details for n00bs like me what GL/2 will be used for?
(Sorry if everyone else here understands...)

Cheers,
Thomas

Being that it's largely just a plug-in replacement for IBM's OpenGL implementation, it really just depends on the user. User's who are heavy into gaming may value speed first. However, users who are into CAD & possibly renderfarms will value precision. In that light, I'd say that it also depends on the app developers. I'm sure that some's going to say that no one develops OpenGL apps for OS/2. However, they really didn't have a reason to until now. And with all of the open-sourced code floating around these days, it'll be much easier to port code over. The large bulk of code that utilizes OpenGL will probably be more easily ported if the Windows version of the app is ported.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

StefanZ

  • Full Member
  • ***
  • Posts: 101
  • My preferred nemesys...
    • View Profile
Re: OpenGL ddk
« Reply #123 on: 2011.01.28, 17:49:55 »
Ah,

now I perfectly understand your concerns.
From the above point of view, I will definitely vote for precision ;)

Thanks a lot for explaining, demetrious  ;)

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #124 on: 2011.01.29, 08:13:14 »
Ah,

now I perfectly understand your concerns.
From the above point of view, I will definitely vote for precision ;)

Thanks a lot for explaining, demetrious  ;)

No problem at all.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

wimpie

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: OpenGL ddk
« Reply #125 on: 2011.01.29, 13:44:19 »
I just voted for precision.

cytan

  • Full Member
  • ***
  • Posts: 213
    • View Profile
Re: OpenGL ddk
« Reply #126 on: 2011.01.29, 16:54:05 »
I vote for a driver that I can test!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #127 on: 2011.01.30, 05:04:52 »
I vote for a driver that I can test!

As nice as that would be, we need a pipeline before we worry about a driver! :P
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #128 on: 2011.01.31, 10:08:04 »
Well, so far the tally's pretty much split evenly with 3 for precision, 3 for speed, & 6 for a mixture of both (which really doesn't apply in the matter of the reason I was asking). So, I decided to go with precision & hope that faster processors help to offset the speed difference. Slower processors are just out of luck. Renderable data will be implemented as 64-bit floating point values.

In other news, I now have a pretty good layout for the pipeline. I'm not sure if I can accurately describe it in words without pictures & diagrams, but I'll try:

Functions that directly change the context will do so immediately. Colors, vertices, normals & things of that nature will be contained in the GL's context until it's time for processing. Processing won't begin until GLEnd() is called. At that point, the context & all of it's gathered data will be sent through the pipeline. All the pipeline does is render the graphics as specified by the data within the context. the only 3D functionality exported by the hardware driver is the entrance to the pipeline function. If there's no hardware pipeline function attached, the pipeline will use it's internal software pipeline.

That's all for now. If there's anyone here with 3D experience & a few comments, tips, or anything helpful to share, now's the time to speak up! :)
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #129 on: 2011.02.08, 19:40:26 »
Well, I guess it's time for another update. I'll admit, I've mostly been sitting at home on my ass since leaving the army. I guess this little break is going to have to do until I can actually take a real vacation. But still, I've got a few thing done on GL/2.

I think I've done a decent job of figuring out which commands can be used in display lists, grouping them up based on functionality, & encoding them in a way that will provide a fair amount of code reuse, allowing me to side step lots of coding &  simplify some of the function implementation into cuts & pastes. There's still quite a bit of work left to do on the actual API, but I've actually knocked out more of it than I thought I would. I'm kinda dragging my feet on it, but sooner or later I'll have to start working on the datatype conversions between all types signed & unsigned to & from floats and doubles. I hope I can find a great conversion system, this needs to be as accurate as possible. Along with the API, I still have to finish working on pipeline management & the actual internal rendering pipeline. I'm also trying to mesh together a driver layer that can be plugged into the GRADD system through the extensions mechanism. Most of the code that I've been working on has been committed to the repo; so, if you think you have some ideas about the driver layer or you have GRADD experience, please, hit me up so we can collaborate. Also, I'm far from a coding God & I haven't tried to build this pipeline yet (I haven't even setup an Open Watcom project for it), so take a look at the code & keep me on track.

I've also been slacking on AL/2 & AGPGART. I'm not sure what it is, but I just can't seem to get a good boiler plate driver up for plugging in AGPGART. I'll keep at it & figure out something, because I'm going to need to be able to communicate with AGPGART when I start work on the memory management portion of GL/2. As for AL/2, it's mainly been a matter of not having time to research OS/2's multimedia API's properly. The great thing about Chris Robinson's OpenAL Soft is that there's really not much needed in order to port it to a new system. It'll need a driver file added that interfaces OpenAL Soft to OS/2's multimedia subsystem & a few additions to parts of the code just to let the library know that there's a new driver included, that's it. I'm slowly dragging myself up outta my slouch, so my productivity will start to kick up again. More later!

Comments, concerns, gripes, or complaints?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #130 on: 2011.02.11, 17:00:08 »
If there're any graphic design specialist out there, I need your help. I just noticed that the OpenGL logo is on the GL/2 page. It must be taken down, since neither myself or anyone else have an OpenGL commercial license. Without the commercial license, we are not allowed to use the OpenGL branding. Which means that this is a great time to start accepting submissions for a GL/2 logo. Keep in mind that if you contribute this logo, you're in fact donating your logo to this project. You will receive full credit for you're work, however, your work will belong to the GL/2 project upon acceptance. So, any takers? Also, I'm looking for a few users to help me judge. Four people, in addition to myself, should be enough to adequately judge submissions. So, I'm looking for submitters & judges, any takers?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Joachim

  • Newbie
  • *
  • Posts: 36
    • View Profile
Re: OpenGL ddk
« Reply #131 on: 2011.02.11, 17:17:45 »
I just noticed that the OpenGL logo is on the GL/2 page. It must be taken down, since neither myself or anyone else have an OpenGL commercial license. Without the commercial license, we are not allowed to use the OpenGL branding.

Hm, my fault - I submitted it to Adrian, didn't realize it was covered by whichever license. I'll notify him it has to be changed.

Sorry,

Joachim

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #132 on: 2011.02.11, 19:51:31 »
Hm, my fault - I submitted it to Adrian, didn't realize it was covered by whichever license. I'll notify him it has to be changed.

Sorry,

Joachim

Well, to be honest, I'm glad you did it. It's jolted me into speaking up on needing a logo. I first wanted to make sure that there was interest in the project, before calling for a logo. However, eventually, most of my time on GL/2 ended up being spent on coding & researching, so it kinda got prioritized out of the forefront. You taking the initiative has reminded me that one's needed & to ask for help. Afterall, coding is just one aspect of the project, so you don't have to be a coder in order to help me! :)
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

melf

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 606
    • View Profile
Re: OpenGL ddk
« Reply #133 on: 2011.02.11, 23:42:33 »
Four people, in addition to myself, should be enough to adequately judge submissions. So, I'm looking for submitters & judges, any takers?
I'll be happy to be one of the judgers. I'm no expert but I like graphics.
/Mikael

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #134 on: 2011.02.12, 00:50:14 »
Four people, in addition to myself, should be enough to adequately judge submissions. So, I'm looking for submitters & judges, any takers?
I'll be happy to be one of the judgers. I'm no expert but I like graphics.

Sounds good to me! Ok, so far I have one additional judge & one submittion. Is there anyone who wouldn't mind temorarily hosting the logos for everyone's viewing pleasure while the contest is up & running? I plan to keep this contest going until the 4th of March. Afterwards, the judges will decide which logo has won. If there are no other submissions, then the current submission will win by default. Though, it's really not a bad logo. It's nice & simple.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!