User(s) browsing this thread: 1 Guest(s)

Poll: how to handle the direct state access extension upgrade
ifdef code to keep maximum compatibility
create a legacy gsdx version
add a compatibility layer
others
[Show Results]
Note: This is a public poll, other users will be able to see what you voted for.
Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
future of GSdx ogl
Author Message
gregory Offline
Linux PCSX2 coder
******

Posts: 2.315
Joined: May 2010
Location: Grenoble, France
Reputation: 46
Post: #11
RE: future of GSdx ogl
Thanks everybody for the feedbacks.

So let's go for 2. I will copy the GSdx directory into GSdx_ogl_legacy. This latest dir will remain untouched. Initially I was planning to keep it only for linux (you know the dx part of GSdx). Anyway it would be possible to add this new version in the buildbot.

Putting ifdef in header is more or less option 3: Compatibility layer. DSA replaces all textures/frambuffer/buffer functions (~30). The mapping is not 1:1 between the 2 api that why code is cleaner. But t won't be straighforward to implement.

For the mass support. You won't need a new gpu, it is purely a sw driver matter.
* I know that mesa wanted to implement the unofficial former dsa ext version. Current arb version is much smaller. Besides modifications are in the common part of mesa. IMHO Mesa dev can implement dsa in a week. It all depends on their priority.
* nvidia branch will likely be merged in a couple of months.
* Remains catalyst case: from one hand they support the previous version so they have a good base. On the other hand, supporting both version of dsa could be annoying with badass inter-dependance.
* globally all dev want dsa. Steam wants dsa, so driver maker will try to support dsa as soon as possible.
09-10-2014 09:23 AM
Find all posts by this user Quote this message in a reply

Sponsored links

Pikasora Offline
Member
**

Posts: 107
Joined: Aug 2014
Location:
Reputation: 0
Post: #12
RE: future of GSdx ogl
(09-10-2014 04:51 AM)Nobbs66 Wrote:  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.

"some" ok
09-12-2014 07:00 AM
Find all posts by this user Quote this message in a reply
Post Reply 





Current time: 12-19-2014, 08:11 PM