On 04/21/2013 04:04 AM, Marek Olšák wrote:
Ah, I didn't know you had any other env vars. It's preferable to have
as many boolean flags as possible handled by a single env var, because
it's easier to use (R600_DUMP_SHADERS counts as a pretty ugly list of
boolean flags hidden behind a magic number)
Ah, I didn't know you had any other env vars. It's preferable to have
as many boolean flags as possible handled by a single env var, because
it's easier to use (R600_DUMP_SHADERS counts as a pretty ugly list of
boolean flags hidden behind a magic number). Feel free to have
separate env vars for mor
On 04/20/2013 07:05 PM, Henri Verbeet wrote:
On 19 April 2013 18:01, Vadim Girlin wrote:
The choice of C++ (unlike in my previous branch that used C) was mostly
driven by the fact that optimization algorithms usually deal with a lot of
different complex data structures, containers, etc, and C++
On 19 April 2013 18:01, Vadim Girlin wrote:
> The choice of C++ (unlike in my previous branch that used C) was mostly
> driven by the fact that optimization algorithms usually deal with a lot of
> different complex data structures, containers, etc, and C++ allows to
> isolate implementation of all
On 04/20/2013 03:38 PM, Christian König wrote:
Am 20.04.2013 13:12, schrieb Vadim Girlin:
On 04/20/2013 01:42 PM, Christian König wrote:
Am 19.04.2013 18:50, schrieb Vadim Girlin:
On 04/19/2013 08:35 PM, Christian König wrote:
Hey Vadim,
Am 19.04.2013 18:18, schrieb Vadim Girlin:
[SNIP]
In
Am 20.04.2013 13:12, schrieb Vadim Girlin:
On 04/20/2013 01:42 PM, Christian König wrote:
Am 19.04.2013 18:50, schrieb Vadim Girlin:
On 04/19/2013 08:35 PM, Christian König wrote:
Hey Vadim,
Am 19.04.2013 18:18, schrieb Vadim Girlin:
[SNIP]
In theory, yes, some optimizations in this branch
On 04/20/2013 01:42 PM, Christian König wrote:
Am 19.04.2013 18:50, schrieb Vadim Girlin:
On 04/19/2013 08:35 PM, Christian König wrote:
Hey Vadim,
Am 19.04.2013 18:18, schrieb Vadim Girlin:
[SNIP]
In theory, yes, some optimizations in this branch are typically used
on the earlier compilatio
Am 19.04.2013 18:50, schrieb Vadim Girlin:
On 04/19/2013 08:35 PM, Christian König wrote:
Hey Vadim,
Am 19.04.2013 18:18, schrieb Vadim Girlin:
[SNIP]
In theory, yes, some optimizations in this branch are typically used
on the earlier compilation stages, not on the target machine code. On
the
On 04/20/2013 03:11 AM, Marek Olšák wrote:
Please don't add any new environment variables and use R600_DEBUG
instead. The other environment variables are deprecated.
I agree, those vars probably need some cleanup, they were added before
R600_DEBUG appeared.
Though I'm afraid some of my optio
Please don't add any new environment variables and use R600_DEBUG
instead. The other environment variables are deprecated.
There is a table for R600_DEBUG in r600_pipe.c and it even comes with
a help feature: R600_DEBUG=help
Marek
On Fri, Apr 19, 2013 at 4:48 PM, Vadim Girlin wrote:
> Hi,
>
> I
On 04/19/2013 08:35 PM, Christian König wrote:
Hey Vadim,
Am 19.04.2013 18:18, schrieb Vadim Girlin:
[SNIP]
In theory, yes, some optimizations in this branch are typically used
on the earlier compilation stages, not on the target machine code. On
the other hand, there are some differences that
Hey Vadim,
Am 19.04.2013 18:18, schrieb Vadim Girlin:
[SNIP]
In theory, yes, some optimizations in this branch are typically used
on the earlier compilation stages, not on the target machine code. On
the other hand, there are some differences that might make it harder,
e.g. many algorithms r
On 04/19/2013 07:13 PM, � wrote:
Hi Vadim,
from your description it seems to be a post processing stage working on
the bytecode of the shaders and additional to that is quite separated
from the rest of the driver.
Yes, currently it's more like a post-processing stage, though on the
other hand
On 04/19/2013 07:23 PM, Henri Verbeet wrote:
On 19 April 2013 16:48, Vadim Girlin wrote:
In the previous status update I said that the r600-sb branch is not ready to
be merged yet, but recently I've done some cleanups and reworks, and though
I haven't finished everything that I planned initiall
On 19 April 2013 16:48, Vadim Girlin wrote:
> In the previous status update I said that the r600-sb branch is not ready to
> be merged yet, but recently I've done some cleanups and reworks, and though
> I haven't finished everything that I planned initially, I think now it's in
> a better state an
Hi Vadim,
from your description it seems to be a post processing stage working on
the bytecode of the shaders and additional to that is quite separated
from the rest of the driver.
If that's the case then I don't really see a reason why we shouldn't
merge it, but at least at the beginning it
Hi,
In the previous status update I said that the r600-sb branch is not
ready to be merged yet, but recently I've done some cleanups and
reworks, and though I haven't finished everything that I planned
initially, I think now it's in a better state and may be considered for
merging.
I'm inte
17 matches
Mail list logo
