(04-08-2016, 01:13 PM)FlatOut Wrote: [ -> ]Yes, it's a 4600.
Then ideally Intel need to know about the bug too, not sure how to report it, but the test program on the AMD link gregory provided should be good enough for them to test with.
Edit: Have you tried updating your Intel drivers?
Edit 2: looks like it was buggy on intel too (might still be), they fixed it in the MESA drivers for linux
https://lists.freedesktop.org/archives/i...07446.html
(04-08-2016, 01:16 PM)refraction Wrote: [ -> ]Then ideally Intel need to know about the bug too, not sure how to report it, but the test program on the AMD link gregory provided should be good enough for them to test with.
Edit: Have you tried updating your Intel drivers?
There are no new updates for my drivers.
(04-08-2016, 01:21 PM)FlatOut Wrote: [ -> ]There are no new updates for my drivers.
Your driver should be dated March 2016 in the device manager then?
(04-08-2016, 01:24 PM)refraction Wrote: [ -> ]Your driver should be dated March 2016 in the device manager then?
No, the March 2016 driver is Windows 10-only.
(04-08-2016, 12:23 PM)FlatOut Wrote: [ -> ]Why is this an AMD bug? A git version from two days ago is fine, and now it's completely ruined unless you set the BUA to Ultra(which makes it unplayably slow).
It is an AMD bug because AMD engineer said it was an AMD bug
And you're right, BUA will workaround the bug. The bug is the configuration of the hardware blending unit. BUA bypass the hardware unit so it is working as expected.
Quote:Then ideally Intel need to know about the bug too, not sure how to report it, but the test program on the AMD link gregory provided should be good enough for them to test with.
Edit: Have you tried updating your Intel drivers?
Edit 2: looks like it was buggy on intel too (might still be), they fixed it in the MESA drivers for linux https://lists.freedesktop.org/archives/i...07446.html
Honestly, it will be strange if they have the same issue. But it could worth to give it a shot on the testcase that I sent to AMD. Mesa bugs were different and partially from me (as I'm the one that implemented the extension on Mesa). As a side note, I'm surprised that you can still run the latest GSdx version, so they did implement several GL4.5 extensions.
(04-08-2016, 01:35 PM)gregory Wrote: [ -> ]As a side note, I'm surprised that you can still run the latest GSdx version, so they did implement several GL4.5 extensions.
is GL_ARB_separate_shader_objects OGL 4.5? I thought it was just 4? If it is 4.5 then that would explain why Intel doesn't work either. It is in Intels list of supported extensions however.
No GL_ARB_separate_shader_objects is from GL4.1 (released somewhere in 2010). However GSdx also required several others GL4.5 such as direct state access/clip control/texture barrier.
I confirm, I used to disable the extension on Intel windows too. But I'm not sure it was ever tested on windows, initially it was for linux.
It's a bit unfortunate that you split into legacy builds... wouldn't it be possible to create new renderer OGL4.5 and rename the old OGL to OGL4 and keep both as parallel renderers? Similar as we do it for dx9/dx10? I think the community would greatly appreciate that. Though I am not sure if that would infer with your work.
(04-08-2016, 01:52 PM)willkuer Wrote: [ -> ]It's a bit unfortunate that you split into legacy builds... wouldn't it be possible to create new renderer OGL4.5 and rename the old OGL to OGL4 and keep both as parallel renderers? Similar as we do it for dx9/dx10? I think the community would greatly appreciate that. Though I am not sure if that would infer with your work.
It'd be nice to do something like this if it's feasible, I don't really think maintaining a legacy version is an ideal solution. ( It just consumes even more effort)