On Thu, Apr 1, 2010 at 12:28 AM, Xavier Bestel xavier.bes...@free.fr wrote:
On Wed, 2010-03-31 at 13:29 +0900, Miles Bader wrote:
Luca Barbieri luca.barbi...@gmail.com writes:
In fact, given the Gallium architecture, it may even make sense to
support a variant of DirectX 10 as the main
Once MS changes interfaces, then there's _no advantage_ to using DX10
internally, regardless of what WINE does, and one might as well use
OpenGL. Wine doesn't change that.
[resent to ML, inadvertently replied only to Miles]
Note that my proposal was not to use DirectX 10 internally, but
On Thu, Apr 1, 2010 at 1:32 AM, Luca Barbieri luca.barbi...@gmail.com wrote:
Once MS changes interfaces, then there's _no advantage_ to using DX10
internally, regardless of what WINE does, and one might as well use
OpenGL. Wine doesn't change that.
[resent to ML, inadvertently replied only
On Wed, 2010-03-31 at 13:29 +0900, Miles Bader wrote:
Luca Barbieri luca.barbi...@gmail.com writes:
In fact, given the Gallium architecture, it may even make sense to
support a variant of DirectX 10 as the main Mesa/Gallium API on all
platfoms, instead of OpenGL.
The apparent benefit
WINE can deal with that. The real showstopper is that WINE has to also
work on MacOS X and Linux + NVIDIA blob, where Gallium is unavailable.
We could actually consider making a Gallium driver that uses OpenGL to
do rendering.
If the app uses DirectX 10, this may not significantly degrade
On Sun, 2010-03-28 at 23:56 -0700, Chia-I Wu wrote:
On Mon, Mar 29, 2010 at 1:51 AM, Keith Whitwell
keith.whitw...@googlemail.com wrote:
I've just pushed a variation on a theme a couple of people have
explored in the past, ie. an interface to gallium without an
intervening state-tracker.
An interesting option could be to provide a DirectX 10 implementation
using TGSI text as the shader interface, which should be much easier
than one would think at first.
DirectX 10 + TGSI text would provide a very thin binary compatible
layer over Gallium, unlike all existing state trackers.
It
On Mon, Mar 29, 2010 at 1:51 AM, Keith Whitwell
keith.whitw...@googlemail.com wrote:
I've just pushed a variation on a theme a couple of people have
explored in the past, ie. an interface to gallium without an
intervening state-tracker.
The purpose of this is for writing minimal test programs
Hi,
I've just pushed a variation on a theme a couple of people have
explored in the past, ie. an interface to gallium without an
intervening state-tracker.
The purpose of this is for writing minimal test programs to exercise
new gallium drivers in isolation from the rest of the codebase.
In
I posted something similar some time ago, that however could use
hardware accelerated drivers with DRI2 or KMS, provided a substantial
set of helpers and offered a complement of 3 demos.
My solution to window-system issues was to simply have the application
provide a draw callback to the
On Sun, Mar 28, 2010 at 12:19 PM, Luca Barbieri luca.barbi...@gmail.com wrote:
I posted something similar some time ago, that however could use
hardware accelerated drivers with DRI2 or KMS, provided a substantial
set of helpers and offered a complement of 3 demos.
My solution to
11 matches
Mail list logo
