From: Tilman Sauerbeck
This makes the 'vp1-LOG test' piglit test work.
Signed-off-by: Tilman Sauerbeck
---
src/gallium/drivers/r600/r600_shader.c | 95 ++--
1 files changed, 90 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/s
Hi Kenneth,
This patch series add GLSL ES support to the standalone compiler.
The first patch makes the standalone compiler to pass a dummy context to
_mesa_glsl_parse_state. The second patch adds a new option, --glsl-es, to
enable GLSL ES mode.
--
o...@lunarg.com
From b36c0eefd7b1ae96eabf72dc
On Wednesday 08 September 2010 04:00:09 Chia-I Wu wrote:
> Hi Kenneth,
>
> This patch series add GLSL ES support to the standalone compiler.
>
> The first patch makes the standalone compiler to pass a dummy context to
> _mesa_glsl_parse_state. The second patch adds a new option, --glsl-es, to
>
On Wed, 2010-09-08 at 03:07 +0200, Luca Barbieri wrote:
> For anyone who doesn't know it yet, there is a new closed-source
> OpenGL game for Linux called Amnesia, with the very interesting
> property that the developers offer a test program that renders several
> complex GLSL-based effects one at a
https://bugs.freedesktop.org/show_bug.cgi?id=30075
Kristian Høgsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
randrianas...@gmail.com writes:
> Very hackish patch series for nv0x hardware, please take look and comment on
> changes, blame me for errors etc.
>
> Francisco, might be nouveau list is better for this stuff?
It's fine either way, do it as you prefer.
> From 9bf16a26361ab4a44b6568deae30c523488
On Tue, 07 Sep 2010 13:08:37 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Luca Barbieri wrote:
> > Well, the alternative is to copy&paste this into ir_lower_jumps and
> > other similar passes.
> >
> > I added a new class instead of changing ir_visitor so that
On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri wrote:
> It would be great if Intel switched to the i915g and i965g Gallium
> drivers, since everyone else is concentrating their attention on
> Gallium, since it's much easier and better to write drivers for it.
I keep hearing this, and a bunch o
> I keep hearing this, and a bunch of people have been trying to build the
> equivalent gallium hardware drivers to various core drivers for a long
> time. So, can we get some details on a success story? What driver is
> now more correct/faster than it was before? By how much? How much of
> tha
On Wed, 8 Sep 2010 18:57:46 +0200, Luca Barbieri wrote:
> S I'd been wanting to do this. Only, I was thinking that instead of
> > adding an ir_binop_all_equal and ir_binop_any_equal, those would just be
> > expressed as not(any(nequal())) and any(equal()). And I say that as
> > probably one of t
> If you're working on a driver for a scalar chip, you might want to pull
> brw_fs_channel_expressions and brw_fs_vector_splitting up and get them
> used -- it should make sensible codegen a lot easier for them.
Current drivers for scalar hardware take Mesa IR/TGSI input and not GLSL IR.
Using GL
On Wednesday 08 September 2010 11:40:24 Luca Barbieri wrote:
> > If you're working on a driver for a scalar chip, you might want to pull
> > brw_fs_channel_expressions and brw_fs_vector_splitting up and get them
> > used -- it should make sensible codegen a lot easier for them.
>
> Current drivers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
>> Clever. :)
>>
>> Technically speaking only the access to the array has undefined
>> behavior, and that undefined behavior does not include program
>> termination.
>
> No, my interpretation is correct, because ARB_robustness con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
>> If you're working on a driver for a scalar chip, you might want to pull
>> brw_fs_channel_expressions and brw_fs_vector_splitting up and get them
>> used -- it should make sensible codegen a lot easier for them.
>
> Current dri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Francisco Jerez wrote:
> randrianas...@gmail.com writes:
>
>> Very hackish patch series for nv0x hardware, please take look and comment on
>> changes, blame me for errors etc.
>>
>> Francisco, might be nouveau list is better for this stuff?
>
> It's
> I think some of the danger lies in constructs like:
>
> for (int i = 0; i < limit; i++)
> if (i < gl_TexCoord.length())
> do_something_with(gl_TexCoord[i]);
> else
> do_something_else();
Yes, you are right.
What
> We intend to change the front-end for ARB fp/vp to generate GLSL IR directly.
Nice.
It's probably a good idea to extend GLSL IR to represent things like
LOG and LIT directly and have optional lowering passes for them, so
that DX9 hardware with native instructions for them can still easily
generat
Ian Romanick writes:
> [...]
>
> At some point it may be worth adding a dri-conf option to enable fake
> ARB_texture_env_combine support. There are a few apps that check for
> that but not for the EXT. I'd swear that NV drivers used to support the
> ARB extension on TNT2 hardware. They did som
On Tue, 2010-09-07 at 22:23 -0700, Tom Stellard wrote:
> Hi,
>
> I have just pushed a branching adding support for presubtract sources to
> my personal repo. The branch contains peephole optimizations for all the
> presubtract operations except for 1 - 2 * src0. I've tested this branch
> on an R
> 2. Compile assembly shaders to GLSL IR (possibly via Mesa IR -> GLSL IR
> translation). This will allow support of other NV assembly extensions
> for free on more advanced GLSL hardware. This will give better support
> for applications that use Cg. The GLSL backend for Cg generates some
> ugl
On Thu, Sep 9, 2010 at 3:28 AM, Eric Anholt wrote:
> On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri
> wrote:
>
>> It would be great if Intel switched to the i915g and i965g Gallium
>> drivers, since everyone else is concentrating their attention on
>> Gallium, since it's much easier and better
Hi,
I'm working with the Khronos Group to implement several EGL extensions in
gallium3d. Up until now, I've been working with a mesa codebase that I
grabbed way back in April. I'm now trying to migrate to the latest version
of mesa (and "rebase" daily) so that I can send my changes to you folk f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
>> We intend to change the front-end for ARB fp/vp to generate GLSL IR directly.
> Nice.
> It's probably a good idea to extend GLSL IR to represent things like
> LOG and LIT directly and have optional lowering passes for them, so
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
> On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri
> wrote:
>
>> It would be great if Intel switched to the i915g and i965g Gallium
>> drivers, since everyone else is concentrating their attention on
>> Gallium, since it's much ea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
> That said, the idea of using a complex language like GLSL as the API
> interface is one of the usual bad design decisions of OpenGL (since,
> for instance, it essentially guarantees incompatibilities, and forces
> everyone implem
On Thu, Sep 9, 2010 at 7:47 AM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Anholt wrote:
>> On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri
>> wrote:
>>
>>> It would be great if Intel switched to the i915g and i965g Gallium
>>> drivers, since everyone else is
> And never mind that you can't make a conformant OpenGL driver with
> Gallium due to the impossibility of software fallbacks.
Well, you could use the failover module to use softpipe for fallbacks,
but no one does, for the following reasons:
1. Modern hardware doesn't need any software fallbacks,
On Wed, 8 Sep 2010 20:40:24 +0200, Luca Barbieri wrote:
> > If you're working on a driver for a scalar chip, you might want to pull
> > brw_fs_channel_expressions and brw_fs_vector_splitting up and get them
> > used -- it should make sensible codegen a lot easier for them.
>
> Current drivers for
On Thu, Sep 9, 2010 at 12:22 AM, Luca Barbieri wrote:
>> And never mind that you can't make a conformant OpenGL driver with
>> Gallium due to the impossibility of software fallbacks.
>
> Well, you could use the failover module to use softpipe for fallbacks,
> but no one does, for the following rea
With some debugging I've figured out that setting EGL_DRIVERS_PATH to
$MESA_ROOT/lib/egl fixes my problem. I'm back in business! ('til I hit the
next roadblock at least). Sorry for the spam.
Cheers,
-Greg Prisament, Lychee Software
On Wed, Sep 8, 2010 at 2:31 PM, Gregory Prisament
wrote:
> Hi
> Structured flow control is the issue. What's the solution for getting
> that back out of LLVM?
Well, my idea is the following.
First, break any self loop edges, then do an SCC decomposition of the
CFG, and output the DAG of the SCCs in topological order.
SCCs that have size 1 are basic blocks,
On Wed, Sep 8, 2010 at 11:47 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Anholt wrote:
>> On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri
>> wrote:
>>
>>> It would be great if Intel switched to the i915g and i965g Gallium
>>> drivers, since everyone else i
> The only people that it helps are people like
> S3 or XGI that don't have a budget to hire a full driver team. For
> everyone else it just plain sucks.
This is the case for all Mesa/Gallium drivers, if you define "full
driver team" by the standards of ATI and nVidia Windows driver teams.
Hence
https://bugs.freedesktop.org/show_bug.cgi?id=29279
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Wed, 8 Sep 2010 20:25:15 +0200, Luca Barbieri wrote:
> > I keep hearing this, and a bunch of people have been trying to build the
> > equivalent gallium hardware drivers to various core drivers for a long
> > time. So, can we get some details on a success story? What driver is
> > now more co
On Wed, 8 Sep 2010 03:07:50 +0200, Luca Barbieri wrote:
> For anyone who doesn't know it yet, there is a new closed-source
> OpenGL game for Linux called Amnesia, with the very interesting
> property that the developers offer a test program that renders several
> complex GLSL-based effects one at
On Wed, 8 Sep 2010 21:30:56 +0200, Luca Barbieri wrote:
>
> Right.
> Is the way talloc is used and works documented anywhere?
> In particular, calling placement new with any part of the IR is always
> equivalent, right?
I need to put some stuff in the readme about this. Actually, instead of
typ
Thanks!
But, does this mean that if I allocate using new(existing_ir) ir_foo()
or opposed to new(talloc_parent(existing_ir)) ir_foo() then this new
object will always remain alive as long as existing_ir is alive, even
if it's no longer referenced?
If so, why would anyone do that, which seems to o
On Thu, Sep 9, 2010 at 2:35 AM, Eric Anholt wrote:
> On Wed, 8 Sep 2010 20:25:15 +0200, Luca Barbieri
> wrote:
>> > I keep hearing this, and a bunch of people have been trying to build the
>> > equivalent gallium hardware drivers to various core drivers for a long
>> > time. So, can we get some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca,
I merged (with some changes) the first 3 patches in your branch.
Tomorrow I will merge "glsl: don't fail if EmitNoIfs and we emitted an
if" with changes to make the i915 reject shaders that still have
if-statements.
I'd like some review from so
On Thu, Sep 9, 2010 at 2:35 AM, Eric Anholt wrote:
> However, the fact that when I ask about performance nobody says "OMG the
> texture upload/download/copy/etc. support in gallium is so great and is
> way faster than anybody managed in classic because it catches all the
> corner cases" makes me
On Thu, Sep 9, 2010 at 6:39 AM, Gregory Prisament
wrote:
> With some debugging I've figured out that setting EGL_DRIVERS_PATH to
> $MESA_ROOT/lib/egl fixes my problem. I'm back in business! ('til I hit the
> next roadblock at least). Sorry for the spam.
There is now a single gallium-based EGL d
Very hackish patch series for nv0x hardware, please take look and comment on
changes, blame me for errors etc.
Francisco, might be nouveau list is better for this stuff?
From 9bf16a26361ab4a44b6568deae30c523488cde1b Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Mon, 6 Sep 2010 18:17:
Hi. I have running linux on my very old machine with nv17 card and I
am impressed that kde4 with nouveau driver work so fast. I am also
curious about few things:
1. In nvfx was implemented sot so long time ago a new 2d engine. It wil
be ported to classic dri driver too ?
2. Will be added s
well, i realized there was too many mistakes on my side. For now it "work" as
not assert during two piglit tests.
results:
Results for glean/texCombine4
Returncode: 0
Errors:
libGL: OpenDriver:
trying /mnt/hdd1/src/mesa-clean/mesa/lib/nouveau_vieux_dri.so
Mesa: Mesa 7.9-devel DEBUG build Sep
В сообщении от Wednesday 08 September 2010 18:41:10 Francisco Jerez
написал(а):
> randrianas...@gmail.com writes:
> > Very hackish patch series for nv0x hardware, please take look and comment
> > on changes, blame me for errors etc.
> >
> > Francisco, might be nouveau list is better for this stuff
sorry, i come to not directly unrelated question:
looking at commit "mesa: initial changes for GL_NV_texture_env_combine4"
http://lists.freedesktop.org/archives/mesa-commit/2009-January/006090.html
i see struct gl_tex_env_combine_state , with some arrays holding texenv
state/parameters.
in nv0
В сообщении от Thursday 09 September 2010 07:18:26 Francisco Jerez написал(а):
> OK, here it is, it was easier to code than to explain :)
-
Thanks, here is my patch series, updated to current (commit
5ecd9c70cecc05eaa1fef05f9bd4e8cf50f2c03a) Mesa. Patch 0004 obviously collides
with your
48 matches
Mail list logo
