On 19 November 2014 01:55, Marek Olšák wrote:
> Before we start discussing what we can do about the OpenGL API
> overhead, we must get rid of the on-demand shader compilation. It's
> unacceptable to compile shaders when we should be rendering. This is
> one of the things that Nine fixes. I assume
On 19 November 2014 00:26, Emil Velikov wrote:
> From a quick look at MSDN it seems to me that going the DDI (like) route
> would require substantial rework on the wine side. How much contribution
> from wine can we expect ? Would you have the chance to help with
> design/coding, or would you be (
Am 18.11.2014 um 23:31 schrieb Emil Velikov :
> Hmm the binaries do not seem to match the source. Am I missing something ?
Not sure. As you can see I've last touched them in January. It is possible that
I have changed some things in the code and not updated the binaries on the
server. I recommen
Before we start discussing what we can do about the OpenGL API
overhead, we must get rid of the on-demand shader compilation. It's
unacceptable to compile shaders when we should be rendering. This is
one of the things that Nine fixes. I assume Wine does that because
there can be several slightly-di
On 18/11/14 18:36, Henri Verbeet wrote:
> On 17 November 2014 21:05, Emil Velikov wrote:
>> - GL extensions
>> I feel that it's a bit too much to shoot the project down, because it
>> does not introduce GL extensions that will be useful.
> To clarify, that's not what I said. It's mostly just that
Hi Stefan,
On 18/11/14 21:21, Stefan Dösinger wrote:
> Am 2014-11-18 19:36, schrieb Henri Verbeet:
>> To clarify, that's not what I said. It's mostly just that I'd like
>> to see some actual evidence for the (implicit) claim that the
>> performance difference is largely due to inherent OpenGL API
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2014-11-18 19:36, schrieb Henri Verbeet:
> To clarify, that's not what I said. It's mostly just that I'd like
> to see some actual evidence for the (implicit) claim that the
> performance difference is largely due to inherent OpenGL API
> overhead.
On 17 November 2014 21:05, Emil Velikov wrote:
> - GL extensions
> I feel that it's a bit too much to shoot the project down, because it
> does not introduce GL extensions that will be useful.
To clarify, that's not what I said. It's mostly just that I'd like to
see some actual evidence for the (
On 17/11/14 20:05, Emil Velikov wrote:
> Henri,
>
> Considering the interface note able, would you say that any new
> implementation towards handling D3D9 in wine is acceptable ? Please note
> that I'm not talking about improving the existing one be that via GL
> extensions or otherwise.
>
> How
On 14/11/14 14:14, Emil Velikov wrote:
> On 02/11/14 18:27, David Heidelberg wrote:
>> Hello everyone!
>>
>> First I'd like thank you for great feedback.
>> Sending third Gallium Nine merge request. We reduced number of commits
>> to necessary minimum. I hope all proposed changes are incorporated i
m: mesa-dev on behalf of Emil
Velikov
Sent: 14 November 2014 14:14
To: David Heidelberg; mesa-dev@lists.freedesktop.org
Cc: emil.l.veli...@gmail.com
Subject: Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 02/11/14 18:27, David Heidelberg wrote:
> Hello everyone!
>
> First I'd like
On 15 November 2014 03:25, Henri Verbeet wrote:
> On 14 November 2014 17:37, Ilia Mirkin wrote:
>> Dave Airlie's virgl work is creating a gallium "driver" which actually
>> uses OpenGL for "hardware". I'm not sure how far he is, but I believe
>> he has enough for GL3. This could be a way forward
While I agree it would be useful to have some D3D features in OpenGL
as extensions to facilitate porting D3D apps to GL, I don't think the
features would be very useful for playing Windows D3D games on Linux,
because I don't believe that translating D3D to GL is even an option
if you want performan
Le 14/11/2014 18:40, Henri Verbeet a écrit :
On 14 November 2014 17:52, Axel Davy wrote:
Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL.
As for me, I contributed only since a few months ago, and was able to
implement a lot of things quite easily, for exemple:
. Resp
On 14 November 2014 17:52, Axel Davy wrote:
> Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL.
> As for me, I contributed only since a few months ago, and was able to
> implement a lot of things quite easily, for exemple:
>
> . Respect the number of backbuffer asked by t
On 14 November 2014 17:42, Jose Fonseca wrote:
>> [...] We'd
>> potentially be open to using something closer to the Gallium interface
>> instead of OpenGL on the backend in wined3d. In that scenario wined3d
>> would essentially be the statetracker. The main issue with that
>> approach has always
On 14 November 2014 17:37, Ilia Mirkin wrote:
> Dave Airlie's virgl work is creating a gallium "driver" which actually
> uses OpenGL for "hardware". I'm not sure how far he is, but I believe
> he has enough for GL3. This could be a way forward towards *only*
> using gallium (since otherwise you'd
On 14/11/2014 17:15, Henri Verbeet wrote :
On 14 November 2014 16:36, Ilia Mirkin wrote:
Is there a different form that you believe would be more likely to be merged?
The main issue is probably that we'd really like to avoid having two
parallel implementations of the high-level d3d9 stuff. [.
n behalf of Henri
Verbeet
Sent: 14 November 2014 16:15
To: Ilia Mirkin
Cc: mesa-dev@lists.freedesktop.org; Emil Velikov; David Heidelberg
Subject: Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 16:36, Ilia Mirkin wrote:
> Is there a different form that you believe would be mor
On Fri, Nov 14, 2014 at 11:15 AM, Henri Verbeet wrote:
> On 14 November 2014 16:36, Ilia Mirkin wrote:
>> Is there a different form that you believe would be more likely to be merged?
>>
> The main issue is probably that we'd really like to avoid having two
> parallel implementations of the high-
On 14 November 2014 16:36, Ilia Mirkin wrote:
> Is there a different form that you believe would be more likely to be merged?
>
The main issue is probably that we'd really like to avoid having two
parallel implementations of the high-level d3d9 stuff. I.e., anything
dealing with (d3d9) devices, st
On Fri, Nov 14, 2014 at 10:31 AM, Henri Verbeet wrote:
> On 14 November 2014 16:21, Ilia Mirkin wrote:
>> To the best of my knowledge, wine has no intent on merging anything
>> related to nine/st.
>>
> That's a bit broader than I'd put it, but yes, in it's current form
> this is not something we'
On 11/14/2014 04:31 PM, Henri Verbeet wrote:
On 14 November 2014 16:21, Ilia Mirkin wrote:
To the best of my knowledge, wine has no intent on merging anything
related to nine/st.
That's a bit broader than I'd put it, but yes, in it's current form
this is not something we'd merge.
At this mome
We plan make automatized tests based on apitrace (documented how to use
it with wine just few days ago) of used games. Also we have wine tests.
About merging to wine, it needs more work to be done, but in generally,
we have packages for wide range of distributions, inlucluding livecd etc.
Maint
On 14 November 2014 16:21, Ilia Mirkin wrote:
> To the best of my knowledge, wine has no intent on merging anything
> related to nine/st.
>
That's a bit broader than I'd put it, but yes, in it's current form
this is not something we'd merge.
___
mesa-dev
On Fri, Nov 14, 2014 at 9:14 AM, Emil Velikov wrote:
> On 02/11/14 18:27, David Heidelberg wrote:
>> Hello everyone!
>>
>> First I'd like thank you for great feedback.
>> Sending third Gallium Nine merge request. We reduced number of commits
>> to necessary minimum. I hope all proposed changes are
On 02/11/14 18:27, David Heidelberg wrote:
> Hello everyone!
>
> First I'd like thank you for great feedback.
> Sending third Gallium Nine merge request. We reduced number of commits
> to necessary minimum. I hope all proposed changes are incorporated in v3.
>
> Thank you
>
Gents,
Can we get an
Hello everyone!
First I'd like thank you for great feedback.
Sending third Gallium Nine merge request. We reduced number of commits
to necessary minimum. I hope all proposed changes are incorporated in v3.
Thank you
Axel Davy (2):
nine: Add drirc options (v2)
nine: Implement threadpool
C
28 matches
Mail list logo
