impossible blend => please read this thread
#11
i think this'll work.

but really, an attachment limit lower than 6K seems absurd

https://mega.co.nz/#!0hZQmTAY!CzvoXwWeHu...SzvTKDmZkE
Reply

Sponsored links

#12
The gta issue is a side effect of render scaling, the half pixel offset helps if I recall.
[Image: ref-sig-anim.gif]

Reply
#13
(05-03-2015, 09:11 PM)Ōkami Amaterasu Wrote: i think this'll work.

but really, an attachment limit lower than 6K seems absurd

It's not supposed to be that low, it's a server misconfig from when we migrated. Hopefully it will get fixed soon.
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
Reply
#14
(05-04-2015, 12:13 AM)refraction Wrote: The gta issue is a side effect of render scaling, the half pixel offset helps if I recall.

Hum I'm need to check but I have the error message so I think it is blending related. It also appears in native mode.
Quote:Impossible blend for D3D: (Cd - Cs) * 128 >> 7 + Cd
Reply
#15
Ok. It is a good gs example. The impossible blend is only used for a single draw call without primitive overlapping. It won't be too costly to emulate it in the fragment shader. However I need to change a bit the architecture of the opengl renderer.
Reply
#16
Would be cool if you can fix that Smile
[Image: ref-sig-anim.gif]

Reply
#17
Yes, I just don't know what will be the best solution.

1/ Either use half-float for the render target (would help color clipping)
Pro => it can be unclamped (be outside of [0:1]). So you can still use the blending unit.
Pro => support primitive that overlap
cons => need a 2nd pass to clamp/wrap the result
cons => bandwidth requirement for big upscale
cons => interaction with texture cache Sad

2/ Either use a FS blending (require GL4.5 extension)
Pro => easier to implement (still use standard render target)
Cons => need to split draw call in non-overlap draw calls
Cons => more FS power requirement for big upscale

It boiled down to the number of time those blending effect are used and how game designer make them (single big sprite (like GTA) or lots of small triangles).
Reply
#18
Well, if it is only a single draw call, the overheads for such an operation shouldn't be too high, considering the first is more compatible it might be better to go with that (aside from the texture cache bit, i feel for you buddy Sad ), it would be also nice as it could benefit the DX side as well in more than just GTA potentially.

So I would say option 1 would be the best solution Smile
[Image: ref-sig-anim.gif]

Reply
#19
the second one would be significantly easier to implement. Are there any examples were the impossible blends are primitively overlapped ? if there aren't any then, why not go for the second one ?
We're supposed to be working as a team, if we aren't helping and suggesting things to each other, we aren't working as a team.
- Refraction
Reply
#20
Hum for 1/
Either we always use an half float RT (colors is 16 bits instead of 8), big cost in all draws calls

Or maybe we could
1/ convert RT from char to half-float
2/ do the draw
3a/ wrap or clamp color
3b/ convert back the RT from half-float to char

I need to check how 1&3b can be done. Maybe 3a/3b can be merged together. This method is interesting because it is transparent for the texture cache.

Quote: the second one would be significantly easier to implement. Are there any examples were the impossible blends are primitively overlapped ? if there aren't any, then why not go for the second one ?
Nobody know. The error message appears only once at the blend state "compilation". Game can reuse it later for a lot of effects.
Reply




Users browsing this thread: 1 Guest(s)