On Fri, 06 Feb 2015 20:53:21 +0100, Roland Scheidegger
wrote:
FWIW I'm wondering why you'd actually need them in a d3d9 state tracker,
as this is a feature first seen with d3d10. Unless you'd want to handle
d3d10 of course, but in this case there's probably not much hope for any
of the d3d9 c
FWIW I'm wondering why you'd actually need them in a d3d9 state tracker,
as this is a feature first seen with d3d10. Unless you'd want to handle
d3d10 of course, but in this case there's probably not much hope for any
of the d3d9 capable hw drivers for lots of reasons...
Roland
Am 06.02.2015 um 1
Michel is right. Nine shouldn't use the blend factors if the driver
doesn't support them.
The removal of the "XXX" comment is okay and can be moved to patch 2.
Marek
On Fri, Feb 6, 2015 at 3:46 AM, Michel Dänzer wrote:
> On 06.02.2015 09:14, David Heidelberg wrote:
>> these days all (r600+,nv50
On 06.02.2015 09:14, David Heidelberg wrote:
> these days all (r600+,nv50+) modern HW support
> PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS Konsole output which r300 don't.
>
> Instead of adding another expensive checks to Nine,
Why would that be expensive? It only needs to be done once per pipe_scre
these days all (r600+,nv50+) modern HW support
PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS Konsole output which r300 don't.
Instead of adding another expensive checks to Nine, this is way to
simply avoid it and do not cause assertion at no cost.
David
On 02/06/2015 12:59 AM, Matt Turner wrote:
On Thu, Feb 5, 2015 at 2:56 PM, David Heidelberg wrote:
> Rather not assert on known factors, just print warning and use ZERO.
... because this allows me to and I cannot fix the
actual bug because of ...?
___
mesa-dev mailing list
mesa-dev@lists.freed
Rather not assert on known factors, just print warning and use ZERO.
Signed-off-by: David Heidelberg
---
src/gallium/drivers/r300/r300_state_inlines.h | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_state_inlines.h
b/src/gallium/driv
