Poll: how to handle the direct state access extension upgrade
You do not have permission to vote in this poll.
ifdef code to keep maximum compatibility
8.33%
2 8.33%
create a legacy gsdx version
83.33%
20 83.33%
add a compatibility layer
8.33%
2 8.33%
others
0%
0 0%
Total 24 vote(s) 100%
* You voted for this item. [Show Results]

future of GSdx ogl
#1
Hello,

opengl 4.5 was released recently with a very interesting extension Direct State Access (aka DSA). Basically this extension replaces the bind to edit (aka B2E) method with a direct access to the object.

I know that severals Dev didn't like B2E. Besides let's be honest DSA is better suited to object oriented code. I also guess that any future GL api will likely based on DSA. So it times to upgrade the codebase Smile

I have already started to port the code to the new extension. But everything isn't perfect.
* DSA replaces lots of opengl function so I'm currently having ifdef all over the place (~50 ifdef). It doesn't help to make code readable and nice.
* Except Nvidia (beta driver), no one support yet DSA. Catalyst can take its time to support it (1 year). I hope Mesa will support it on next release (6 months) but nobody know.
* GLES3.1 doesn't support at all DSA. I hope dev will push for it, but hardware vendor will likely push against it (to keep driver as easy as possible).

I'm mitigate how to handle this situation
1/ keep the ifdef.
+ support everyone
- code readability
2/ Copy GSdx into a legacy gsdx-ogl for linux user. That will be dropped when the 3 drivers implement the extension
+ cleanest code
- drop GLES3.1 (of the future GSdx, legacy will stay for refence). Note situation could be temporary.
3/ Add compatibility layer to emulate the new function.
+ additional work...
- slow
+ clearner code but not yet perfect

Any opinion is welcome..

Sponsored links

#2
If you want to use the new model, then I suggest you create a legacy branch of GSdx and move on.
We're a small team and need to focus our time. Tons of #ifdef create a lot of maintenance work and
it won't be fun to duplicate all new functions anyway. Also you'd have to implement everything twice!
A compatibility layer is the big corporate choice. We lack about 200 coders to go that route Laugh
#3
I agree that legacy branch is probably the best way. Clean code is a priority right now.
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
#4
Hmm. I ask this without knowing the work involved.

Would it be possible to simply keep the current one and work on a new plugin (so that both plugins are included in the download). That way the people with older cards can still use GDSX without compiling it. Or at the very least keeping a copy of the current one that people could easily download?

Other than that, I'm all for just no longer maintaining the current code and moving onto a new plugin.
#5
^ That's basically what making a legacy branch is. Make a copy of the current plugin source, for people to use in the meantime. Then continue working on the code from there.
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
#6
(09-09-2014, 10:09 PM)Blyss Sarania Wrote: ^ That's basically what making a legacy branch is. Make a copy of the current plugin source, for people to use in the meantime. Then continue working on the code from there.

I get that, but in most projects, that usually requires people to compile it. I'd prefer if it came compiled with the emulator.
#7
I think it would? As I understand it, the "legacy" version would continue to be available with the bundle. We already have several versions of GSdx anyway. What's one more? Tongue2
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
#8
As long as the buildbot compiles it... If you don't remove it or put other effort into it there should be no difference to the current situation


I am quite unexperienced with C++ but have recently often seen solutions like those (using macros and typedefs):

Code:
#ifdef OGL4.5
   typedef buffer *uint32_t
   define nextelem(current) (*current+10)
   [...]
#elif GLES3.1
   typedef buffer *uint16_t
   define nextelem(current) (*current+8)
   [...]
#else
   //error
#endif

To me this looks awkward but it seems to be a possible solution (I think for x64/x86 compatibility this is sometimes used). So the question is: Instead of puting 60 ifdefs into the source can you put all in the just in header and use typedefs/macros in the end?
#9
Not a dev but I have voted for n°2. It seems to be the most efficient way.
Maybe some guys won't be able to use your latest improvement on GSdx for ~1 year ... Well, it's the game. Not a problem if it allow you to give us the best (possible) of Gsdx after this one year of development Smile
Keep the good work gregory (and the other guys too) !
#10
Yeah #2 seems best. Even if we drop compatibility for some people we still have to look to the future and do whats most feasible. Like rama said, we don't have the man power for option #3 and #1 isn't a good option because it may prevent other devs from working on the source code due to the complexity of it.
[Image: gmYzFII.png]
[Image: dvedn3-5.png]




Users browsing this thread: 1 Guest(s)