Hi,
Another area of Apitrace I'm struggling with is Android support, because:
- I don't have a feeling if / how much it actually matters to users
- I have no idea if it even works or not
I'm afraid the status quo is unbearable, whereby Android support is
officially advertised, but users keep co
On Sat, Jun 15, 2013 at 8:05 PM, Carl Worth wrote:
> José Fonseca writes:
> > FYI, with
> >
> https://github.com/apitrace/apitrace/commit/7700f74f294a28e57860487b917c8807156b3ad1
> > apitrace no longer crashes with Steam overlay.
>
> Thanks, José! This will be q
On Tue, Mar 5, 2013 at 9:11 AM, Alexander Monakov wrote:
>
>
> On Mon, 4 Mar 2013, Carl Worth wrote:
>
> > I don't think it should be too hard to get this to work, (though it
> > may require a source change to the Steam overlay). I'll do some more
> > experiments tomorrow and see if I can't make a
t; Cc: mesa-dev@lists.freedesktop.org; apitr...@lists.freedesktop.org
> Subject: Re: [Mesa-dev] and a random apitrace/gallium question..
>
> On Mon, Jun 3, 2013 at 11:56 AM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> On Mon, Jun 3, 2013 at 10
(Switching from dead mesa3d-...@sf.net -> mesa-...@fdo.org ML)
On Thu, Jan 17, 2013 at 11:23 PM, Sedat Dilek wrote:
> Hi,
>
> with the following patchset (13 patches) I was able to build
> mesa-8.0.5 with LLVM v3.2.
>
> There is one big fat patch called "gallivm,draw,llvmpipe: Support
> wider nat
On Sun, Mar 11, 2012 at 7:00 PM, José Fonseca wrote:
> On Sun, Mar 11, 2012 at 6:59 PM, Dave Airlie wrote:
>> (resend to include list, I only sent it to Jose by accident).
>>
>> On Fri, Mar 9, 2012 at 8:22 PM, José Fonseca
>> wrote:
>>> There are several n
On Sun, Mar 11, 2012 at 6:59 PM, Dave Airlie wrote:
> (resend to include list, I only sent it to Jose by accident).
>
> On Fri, Mar 9, 2012 at 8:22 PM, José Fonseca wrote:
>> There are several new features in apitrace that deserve an announcement:
>
> I had an idea for a &q
There are several new features in apitrace that deserve an announcement:
* Top-level `apitrace` command which greatly simplifies using apitrace
from command line (Carl Worth from Intel Inc.)
* Trace and retrace support for EGL, GLES1, and GLES2 APIs on Linux
(Chia-I Wu from LunarG Inc., plus port
MinGW uses MSVC's runtime DLLs for most of C runtime's functions, and
there has same semantics for vsnprintf.
Not sure how this worked until now -- maybe one of the internal
vsnprintf implementations was taking precedence.
---
src/glsl/ralloc.c |8 +++-
1 files changed, 7 insertions(+),
There were a bunch of features accumulated on apitrace's master
branch, so I've tagged version 2.0:
* Flush/sync trace file only when there is an uncaught signal/exception,
yielding a 5x speed up while tracing.
* Employ google snappy compression library instead
of zlib, yielding a further 2x
FYI, I documented examples of more advanced debugging techniques using
apitrace, meant specifically for GL driver development (as opposed to
GL application development). In particular:
- how to prepare a regression test case (*)
- how to automate git bisect to find a commit which introduced a reg
FYI, over these past months I've been continuing to improve glretrace
on my spare time, and lifted several of the previous limitations:
added support for DrawArrays/Elements with user pointers;
Map/UnmapBuffer; more extensions; several bug fixes. To the point that
a great deal of GL apps trace & re
On 04/15/2011 09:14 PM, José Fonseca wrote:
On 04/15/2011 08:51 PM, Brian Paul wrote:
On 04/15/2011 01:41 PM, José Fonseca wrote:
On 04/15/2011 07:20 PM, Christoph Bumiller wrote:
On 15.04.2011 18:04, Brian Paul wrote:
Hi Marek,
Back on Jan 10 you removed the per-vertex
On 04/15/2011 08:51 PM, Brian Paul wrote:
On 04/15/2011 01:41 PM, José Fonseca wrote:
On 04/15/2011 07:20 PM, Christoph Bumiller wrote:
On 15.04.2011 18:04, Brian Paul wrote:
Hi Marek,
Back on Jan 10 you removed the per-vertex array max_index field
(commit
On 04/15/2011 07:20 PM, Christoph Bumiller wrote:
On 15.04.2011 18:04, Brian Paul wrote:
Hi Marek,
Back on Jan 10 you removed the per-vertex array max_index field
(commit cdca3c58aa2d9549f5188910e2a77b438516714f). I believe this was
a mistake.
I noticed today that the piglit draw-instance
Manuel,
Yeah. I ran into the bogus warnings over the weekend and pushed a fix
this morning:
commit dcbc9be38ecea30506198d0db037cbf532f070e4
Author: José Fonseca
Date: Tue Apr 5 21:35:11 2011 +0100
draw: Fix thinko in debug warnings.
Thanks for letting me know.
Jose
On 04/06/2011
On 03/31/2011 09:45 PM, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/31/2011 06:46 AM, jfons...@vmware.com wrote:
From: José Fonseca
Not added to the standard test lists given that ARB_vertex_buffer_object
allows program termination out-of-bounds vertex buffer
On 03/31/2011 09:38 PM, Eric Anholt wrote:
On Thu, 31 Mar 2011 14:46:32 +0100, jfons...@vmware.com wrote:
+/* Test whether out-of-bounds vertex buffer object cause termination.
+ *
+ * Note that the original ARB_vertex_buffer_object extension explicitly states
+ * program termination is allo
On 03/27/2011 04:11 PM, Tobias Droste wrote:
In llvm-2.9 Target->createMCInstPrinter() takes different arguments
Signed-off-by: Tobias Droste
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxi
On Tue, 2011-03-15 at 13:26 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/15/2011 08:29 AM, José Fonseca wrote:
> > Attached is a new version of the patch that keeps the extensions sorted
> > alphabetically in the source code, and
On Sat, 2011-03-12 at 01:22 -0800, Kenneth Graunke wrote:
> On Friday, March 11, 2011 01:23:12 PM Patrick Baggett wrote:
> > I feel like there is some kind of underlying lesson that we, OpenGL app
> > programmers, should be getting out of this...
>
> Yes. Don't blindly copy abitrary amounts of da
On Mon, 2011-03-14 at 10:55 -0700, Gustaw Smolarczyk wrote:
> The commit 110f5e2056f80d0b87f2a4388bc35727070ba6d5 was meant to fix
> this build error, but it only add x86disassembler. The macro
> InitializeAllDisassemblers() (from llvm/Target/TargetSelect.h)
> initializes *all* disassemblers build
On Mon, 2011-03-14 at 11:23 -0700, Brian Paul wrote:
> On 03/12/2011 07:44 PM, Marek Olšák wrote:
> > The r300 compiler can eliminate unused uniforms and remap uniform locations
> > if their number surpasses hardware limits, so the limit is actually
> > NumParameters + NumUnusedParameters. This is
On Mon, 2011-03-14 at 10:06 -0700, Matt Turner wrote:
> On Mon, Mar 14, 2011 at 4:52 PM, José Fonseca wrote:
> > If we want a cleaner / more agile code base, then we could fork off the
> > old mesa drivers which aren't being actively maintained/tested into a
> > separat
I also agree with Marek FWIW.
If we want a cleaner / more agile code base, then we could fork off the
old mesa drivers which aren't being actively maintained/tested into a
separate branch, put them in just-bugfixes/no-new-features life support
mode; therefore allowing greater freedom to refactor s
On Fri, 2011-03-11 at 09:04 -0800, Eric Anholt wrote:
> On Fri, 11 Mar 2011 10:33:13 +0000, José Fonseca wrote:
> > The problem from
> >
> > http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12493.html
> >
> > is back, and now a bit worse -- it
Look ok to me..
Jose
On Thu, 2011-03-10 at 20:32 -0800, Marek Olšák wrote:
> Hi,
>
> I have done some of the changes in the gallium interface we discussed in the
> thread called "7 questions...".
>
> There are 4 patches in total:
>
> 1) gallium: kill is_resource_referenced
>
> The function i
On Fri, 2011-03-11 at 02:06 -0800, Thomas Hellstrom wrote:
> On 03/10/2011 04:57 PM, José Fonseca wrote:
> > On Thu, 2011-03-10 at 06:01 -0800, Thomas Hellstrom wrote:
> >
> >> Make sure that the upload manager doesn't upload data that's not
> >> dirt
The problem from
http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12493.html
is back, and now a bit worse -- it causes Quake3 arena demo to crash (at
least the windows version). The full version works fine. I'm not sure
what other applications are hit by this. See the above thread
On Thu, 2011-03-10 at 06:01 -0800, Thomas Hellstrom wrote:
> Make sure that the upload manager doesn't upload data that's not
> dirty. This speeds up the viewperf test proe-04/1 a factor 5 or so on svga.
Sweet!
A few comments inline
> Also introduce an u_upload_unmap() function that can be used
On Mon, 2011-03-07 at 02:38 -0800, Keith Whitwell wrote:
> On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
> > 2) is_resource_referenced
> >
> > Now that the transfer functions are in pipe_context, is this hook
> > really
> > necessary?
>
> Good question. I'd like to see those functions go
Nice catch.
Jose
On Mon, 2011-03-07 at 02:24 -0800, Thomas Hellstrom wrote:
> st->user_vb[attr] was always pointing to the same user vb, regardless
> of the value of attr. Together with reverting the temporary workaround
> for bug 34378, and a fix in the svga driver, this fixes googleearth on svg
On Thu, 2011-02-24 at 08:43 -0800, Chris Wilson wrote:
> Module: Mesa
> Branch: master
> Commit: c0ad70ae31ee5501281b434d56e389fc92b13a3a
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=c0ad70ae31ee5501281b434d56e389fc92b13a3a
>
> Author: Neil Roberts
> Date: Sat Feb 5 10:21:11 2
On Fri, 2011-02-18 at 08:38 -0800, Brian Paul wrote:
> On 02/18/2011 09:15 AM, jfons...@vmware.com wrote:
> > From: Keith Whitwell
> >
> > ---
> > src/gallium/include/pipe/p_defines.h | 19 +--
> > 1 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/galli
A bit more background about this: this flag allows to get discard from
the app down to the kernel, where most memory managers are able to do
discard while mapping level without the whole map-non-block +
create/destroy resource roundtrip. This is Keith's idea.
Jose
On Fri, 2011-02-18 at 08:15 -0
On Mon, 2011-02-14 at 11:04 -0800, Marek Olšák wrote:
> On Mon, Feb 14, 2011 at 6:58 PM, José Fonseca
> mailto:jfons...@vmware.com>> wrote:
> Marek,
>
> I'm OK with removing pipe_vertex_buffer::max_index but there is a bit
> more work involved, as they are not really
On Mon, 2011-02-14 at 15:13 -0800, Brede Johansen wrote:
> Hi,
>
> I have made VS2008 project and solution files based on the scons
> files. I have also included generation of necessary source files from
> python as part of the build. This also works in VS2010.
> My requirement was to get OpenGL
On Mon, 2011-02-14 at 10:18 -0800, Marek Olšák wrote:
> On Mon, Feb 14, 2011 at 6:47 PM, José Fonseca
> mailto:jfons...@vmware.com>> wrote:
> On Sun, 2011-02-13 at 23:58 -0800, Dave Airlie wrote:
> > >>if(buf->base.base.size < size)
> > >>
Marek,
Apart of some subtleties with removing pipe_vertex_buffer::max_index, I
think this looks great.
I'm OK with addressing the pipe_vertex_buffer::max_index issues after
commiting this series, as well behaved applications should not be
affected.
Jose
On Sat, 2011-02-12 at 11:05 -0800, Marek
Marek,
I'm OK with removing pipe_vertex_buffer::max_index but there is a bit
more work involved, as they are not really equivalent in the guarantees.
pipe_vertex_buffer::max_index is an attribute of the vertex buffer -- it
describe the max index that can be fetch from the buffer without running
i
On Sun, 2011-02-13 at 23:58 -0800, Dave Airlie wrote:
> >>if(buf->base.base.size < size)
> >> return 0;
> >>
> >> @@ -242,13 +240,10 @@ pb_cache_is_buffer_compat(struct pb_cache_buffer
> >> *buf,
> >>if(!pb_check_usage(desc->usage, buf->base.base.usage))
> >> return 0;
> >>
> >>
On Thu, 2011-02-10 at 02:06 -0800, Christoph Bumiller wrote:
> On 10.02.2011 09:47, José Fonseca wrote:
> > On Wed, 2011-02-09 at 17:55 -0800, Dave Airlie wrote:
> >> On Thu, Feb 10, 2011 at 11:27 AM, Marek Olšák wrote:
> >>> In this case, we always use the
On Wed, 2011-02-09 at 17:55 -0800, Dave Airlie wrote:
> On Thu, Feb 10, 2011 at 11:27 AM, Marek Olšák wrote:
> > In this case, we always use the corresponding linear format in
> > create_surface,
> > therefore we should check for linear format support as well.
>
> Seems sane to me.
>
> Dave.
Looks good to me FWIW.
When dst_reg.reladdr is set we could still restrict the reset to
dst_reg.writemask bits, but this was not done before either.
Jose
On Fri, 2011-02-04 at 12:50 -0800, Eric Anholt wrote:
> Fixes glsl-vs-post-increment-01.
> ---
> src/mesa/program/ir_to_mesa.cpp | 47 +
Eric,
This code is causing segmentation faults on cinebench r11:
Program received signal SIGSEGV, Segmentation fault.
0x76d3d7fd in exec_node::remove (this=0x1501590) at src/glsl/list.h:125
125 next->prev = prev;
(gdb) bt
#0 0x76d3d7fd in exec_node::remove (this=0x15015
On Fri, 2011-02-04 at 15:26 -0800, Benoit Jacob wrote:
>
> - Original Message -
> > On Fre, 2011-02-04 at 14:21 -0800, Benoit Jacob wrote:
> > >
> > > - Original Message -
> > > > Benoit Jacob wrote:
> > > > > - Original Message -
> > > > >> On Thu, Feb 3, 2011 at 4:37 PM,
On Fri, 2011-02-04 at 09:58 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/03/2011 10:36 PM, Jose Fonseca wrote:
> > This is very odd behavior from Sun's compiler -- unless we include
> > cstdio, printf should be available, not std::printf.
>
> I think we m
On Mon, 2011-01-31 at 11:48 -0800, Christoph Bumiller wrote:
> On 31.01.2011 19:46, Marek Olšák wrote:
> > With this manager, the drivers don't have to deal with user buffers when
> > they are bound as vertex buffers. They only get real hardware buffers.
>
> Please do *not* take away my user buff
Looks perfect. Thanks for doing this Marek.
Jose
On Thu, 2011-01-27 at 11:32 -0800, Marek Olšák wrote:
> Module: Mesa
> Branch: master
> Commit: 387fe8dd475d70f098eabc48a8a3696cf0b72275
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=387fe8dd475d70f098eabc48a8a3696cf0b72275
>
> Aut
On Thu, 2011-01-27 at 13:07 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/26/2011 06:16 PM, Zack Rusin wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 59dbdbbb7d0ff90dc7561b1bc337bbb918755103
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/com
me that the depth buffer is ok)
>
> - The GLSL depth-write shader doesn't work when the texture format
>is DEPTH_COMPONENT. I've changed it to LUMINANCE16 when running
>on Mesa/VMWare.
>
> Again, thanks for the help.
>
> Stefan
>
>
> Zitat von José F
On Mon, 2011-01-24 at 20:52 -0800, Marek Olšák wrote:
> Let's assume there are two options with names such that one is a substring
> of another. Previously, if we only specified the longer one as a debug option,
> the shorter one would be considered specified as well (because of strstr).
> This com
eadPixels is ok.
>
> Regards,
>
> Stefan
>
>
> Zitat von José Fonseca :
>
> > On Tue, 2011-01-25 at 01:13 -0800, stef...@starnberg-mail.de wrote:
> >> Hi,
> >>
> >> i'm trying to get one of our testsuites running in VMWare
> >> (V
On Sat, 2011-01-22 at 19:18 -0800, Chad Versace wrote:
> On Sat, Jan 22, 2011 at 17:46, Ian Romanick wrote:
> > What I want is a way with cmake to build files twice. The first time
> > will be in the existing way. The second time will compile with
> > - -DUSE_OPENGL_ES and will generate a .o fil
Sorry for the delay. I thought I had replied but didn't.
On Fri, 2011-01-21 at 01:04 -0800, Chia-I Wu wrote:
> On Fri, Jan 21, 2011 at 12:18 AM, José Fonseca wrote:
> > Hi Olv,
> >
> > Looks good to me FWIW.
> Thanks.
> > I think we should avoid hav
On Tue, 2011-01-25 at 01:13 -0800, stef...@starnberg-mail.de wrote:
> Hi,
>
> i'm trying to get one of our testsuites running in VMWare
> (VMware, Inc. Gallium 0.3 on SVGA3D; build: RELEASE; OGL 2.1 Mesa
> 7.7.1-DEVEL).
> With the GDI backend everything works fine (tested in 7.7,7.8,7.10).
>
>
Hi Olv,
Looks good to me FWIW.
I think we should avoid having opengl32.dll or the ICD loading
glapi.dll, but that's not a reason to s given you've made it optional.
Implementing EGL on Windows without implementing GL doesn't make much
sense, so we could have GLES libraries dynamically loading
I've fixed the getopt.h dependency and talloc linking. MSVC is now
building without errors.
MinGW cross-compilation is still broken because a different compiler
must be used for builtin_functions (ordinary gcc instead of
i586-mingw32msvc-gcc)
This was also necessary for Michal's glsl frontend, s
This breaks cross-compilation because builtin_function.cpp needs to be
built with the native compiler, instead of the cross compiler.
I see there is a python program too. Is this native program unavoidable?
Jose
On Sat, 2011-01-08 at 21:53 -0800, Kenneth Graunke wrote:
> Now that this works with
Commited. Thanks.
Jose
On Thu, 2011-01-06 at 11:58 -0800, kristof.ralov...@gmail.com wrote:
> On 2011-01-04, José Fonseca wrote:
> > Kristof,
> >
> > It looks good overall with the exception that the build will fail if the
> > EGL library is not available.
&
Jerome,
Hmm. B8G8R8A8 -> B8G8R8X8 should be accepted by
util_is_format_compatible.
It looks like util_is_format_compatible arguments are swapped, ie., it
should be
assert(util_is_format_compatible(util_format_description(src->format),
util_format_description(dst->format)));
instead of
On Mon, 2010-12-06 at 17:10 -0800, Carl Worth wrote:
> On Mon, 06 Dec 2010 20:23:52 +0000, José Fonseca wrote:
> > I suppose it is possible for space to be significant on a conditional
> > expression, e.g.,
> >
> > #if foo ()
> >
> > vs
> &g
On Mon, 2010-12-06 at 23:27 -0800, tom fogal wrote:
> Jose Fonseca writes:
> > I can remove python2.6 dependency as you suggest, but although this
> > new string formatting method is seldom used it actually makes the
> > code much more readable and I was hoping to spread its use, so I'd
> > like y
On Fri, 2010-12-03 at 15:37 -0800, Carl Worth wrote:
> On Fri, 3 Dec 2010 13:34:09 -0800, Kenneth Graunke
> wrote:
> > On Friday 03 December 2010 08:01:06 José Fonseca wrote:
> > > parser->space_tokens = 1;
> > >
> > > statement conditional_tok
On Mon, 2010-12-06 at 10:58 -0800, Brian Paul wrote:
> I'd like to simply try --cppflags for now and see if that fixes the
> problem for us. There's a few -D flags that we also need; it's not
> just the -I path.
I agree.
The scons build has been using --cppflags since the very beginning. I
d
Hi Ian,
The current GLSL preprocessor fails to parse expressions such as
#if 1 == 0 || defined UNDEFINED
which is used by CINEBENCH r11.
The problem is the
parser->space_tokens = 1;
statement conditional_tokens stanza -- it causes space tokens to be
emitted halfway before reaching the DEF
FYI, I've extended my apitrace project to be able not only to show a
list of GL calls, but also replay them.
The idea is to facilitate reproduction of bugs, help finding
regressions, and do it across different platforms.
Code is in
http://cgit.freedesktop.org/~jrfonseca/apitrace/log/?h=retrace
On Tue, 2010-11-16 at 11:55 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/15/2010 05:48 PM, Brian Paul wrote:
>
> > case ir_unop_b2f:
> >assert(op[0]->type->base_type == GLSL_TYPE_BOOL);
> >for (unsigned c = 0; c < op[0]->type->componen
On Wed, 2010-11-10 at 13:24 -0800, Marek Olšák wrote:
> On Wed, Nov 10, 2010 at 9:48 PM, José Fonseca
> mailto:jfons...@vmware.com>> wrote:
> On Wed, 2010-11-10 at 12:29 -0800, Marek Olšák wrote:
> > Required because ATI and NVIDIA DX9 GPUs do not support indirect addressing
On Wed, 2010-11-10 at 12:29 -0800, Marek Olšák wrote:
> Required because ATI and NVIDIA DX9 GPUs do not support indirect addressing
> of temps, inputs, outputs, and consts (FS-only) or the hw support is so
> limited that we cannot use it.
>
> This should make r300g and possibly nvfx more feature c
SCons is very powerful (the only crossplatform tool with convenience
library support that I know), but there it requires a lot of
costumization (i.e, all scons/*.py). It's worth the time investment for
Mesa/Gallium drivers, but don't feel like maintain all that glue
everywhere.
For simple stuff li
On Thu, 2010-11-04 at 09:58 -0700, Michal Krol wrote:
> W dniu 2010-11-04 17:56, José Fonseca pisze:
> > Michal,
> >
> > I think we can just use binary all the time.
> >
>
> Really? There are some consumers of this function that produce text
> files, like XM
Michal,
I think we can just use binary all the time.
Jose
On Thu, 2010-11-04 at 09:29 -0700, Michal Krol wrote:
> From efd52ac32547c80d1d8317fe2934a6742968a394 Mon Sep 17 00:00:00 2001
> From: Michal Krol
> Date: Thu, 4 Nov 2010 17:29:01 +0100
> Subject: [PATCH] os: Allow file streams to be ope
I've just pushed a long time requested improvement to scons build
system.
Now is simply a matter of naming what to build. For example:
scons libgl-xlib
scons libgl-gdi
scons graw-progs
scons llvmpipe
and so on. And there is still the possibility of scepcified subdirs,
e.g.
scons sr
On Wed, 2010-10-27 at 08:50 -0700, Vinson Lee wrote:
>
> > -Original Message-
> > From: mesa-dev-bounces+vlee=vmware@lists.freedesktop.org [mailto:mesa-
> > dev-bounces+vlee=vmware@lists.freedesktop.org] On Behalf Of José
> > Fonseca
> > Sent: We
On Mon, 2010-10-18 at 10:52 -0700, Keith Whitwell wrote:
> On Mon, Oct 18, 2010 at 9:18 AM, Jerome Glisse wrote:
> > On Fri, Oct 15, 2010 at 7:44 PM, John Kessenich wrote:
> >> Hi,
> >> LunarG has decided to work on an open source, long-term, highly-functional,
> >> and modular shader and kernel
On Tue, 2010-10-12 at 07:58 -0700, Brian Paul wrote:
> On 10/12/2010 02:06 AM, José Fonseca wrote:
> > What you guys feel about anonymous unions?
> >
> > I happened to committed some code with anonymous unions, but it caused
> > gcc to choke when -std=c99 option
On Mon, 2010-10-11 at 14:49 -0700, Ian Romanick wrote:
> As has been discussed numerous times, the
> assembly-like IRs in Mesa (classic Mesa IR and TGSI) are completely
> useless for generating code for GPUs. llvmpipe has shown that they are
> also completely useless for generating code for CPUs.
What you guys feel about anonymous unions?
I happened to committed some code with anonymous unions, but it caused
gcc to choke when -std=c99 option is specified, which is only specified
with automake but scons.
After some search, it looks like anonymous unions are not part of C99,
but are part of
> +verts[15] = 0.6 # a2
> +
> verts[16] = 0.8 # x3
> verts[17] = -0.8 # y3
> verts[18] = 0.8 # z3
> verts[19] = 1.0 # w3
> -verts[20] = 0.0 # r3
> -verts[21] = 0.0 # g3
> - verts[22] = 1.0 # b3
> +
> +verts[20
On Thu, 2010-09-30 at 10:19 -0700, Roland Scheidegger wrote:
> On 30.09.2010 16:44, José Fonseca wrote:
> > On Thu, 2010-09-30 at 07:32 -0700, Brian Paul wrote:
> >> On 09/30/2010 12:41 AM, Dave Airlie wrote:
> >>> some background:
> >>>
> >>&
On Thu, 2010-09-30 at 07:57 -0700, Brian Paul wrote:
> On 09/29/2010 07:34 PM, Dave Airlie wrote:
> > So I've been playing with stencil writing on r600, and it lead me to
> > examine the depth writing.
> >
> > So at the moment in gallium if we are writing to depth via DrawPixels,
> > we construct a
On Thu, 2010-09-30 at 07:44 -0700, José Fonseca wrote:
> On Thu, 2010-09-30 at 07:32 -0700, Brian Paul wrote:
> > On 09/30/2010 12:41 AM, Dave Airlie wrote:
> > > some background:
> > >
> > > so on r600g, the only way to directly write to the stencil is via the
On Thu, 2010-09-30 at 07:32 -0700, Brian Paul wrote:
> On 09/30/2010 12:41 AM, Dave Airlie wrote:
> > some background:
> >
> > so on r600g, the only way to directly write to the stencil is via the
> > shader, using a transfer would require an extra step to flush the DS
> > buffer out via the pipe a
I didn't test but looks fine to me. Please commit.
Jose
On Wed, 2010-09-29 at 12:37 -0700, tom fogal wrote:
> ping?
>
> -tom
>
> tom fogal writes:
> > A friend of mine had trouble building 7.8.2 on an old gcc3.3 system
> > (no gcc intrinsics). I put together this patch and he said his build
>
Could you please send me the modified tri.py as well. Thanks
Jose
On Wed, 2010-09-29 at 07:41 -0700, Igor Oliveira wrote:
> Hi Jose,
>
> I updated the patch(see below), I am using python samples, modifying
> the tri.py to use it because the regress tests are outdated.
> Now we have we can get th
On Tue, 2010-09-21 at 07:13 -0700, Luca Barbieri wrote:
> > Is there any reason for the binaries to be commited?
>
> The idea is to allow people to test (to be added) Wine support or run
> the demos in Windows to see what they are supposed to do without
> needing to setup a Windows build environme
On Tue, 2010-09-21 at 02:14 -0700, Jakob Bornecrantz wrote:
> On Tue, Sep 21, 2010 at 10:42 AM, Keith Whitwell wrote:
> > On Mon, 2010-09-20 at 16:28 -0700, Luca Barbieri wrote:
> >> > A couple of questions - it looks like this is a drop-in for the
> >> > d3d10/11 runtime, rather than an implement
On Tue, 2010-09-21 at 05:00 -0700, Henri Verbeet wrote:
> On 21 September 2010 13:13, Luca Barbieri wrote:
> > Why are you claiming this?
> > I assume it's because of the comment in tpf.h, which states that it
> > has been written according to Microsoft's documentation, which is
> > available sole
Tilman,
Fell free to push this and future fixes to the python scripts. They
haven't received any love for some time, especially after graw.
Jose
On Sun, 2010-09-19 at 12:57 -0700, Tilman Sauerbeck wrote:
> Signed-off-by: Tilman Sauerbeck
> ---
>
> The same fix needs to be applied to a bunch of
Hi Jakob,
On Sat, 2010-09-18 at 07:30 -0700, Jakob Bornecrantz wrote:
> On Sat, Sep 18, 2010 at 4:26 PM, Jakob Bornecrantz
> wrote:
> > Looking over some of the piglit failings that Vinsons have posted running
> > on softpipe (we are down to 3005/3048). At first I was just going to make
> > the
On Thu, 2010-09-16 at 11:44 -0700, Vinson Lee wrote:
> g++ -o build/linux-x86-debug/glsl/loop_controls.os -c -O0 -g3 -m32
> -mstackrealign -mmmx -msse -msse2 -Wall -Wno-long-long -ffast-math
> -fmessage-length=0 -Wmissing-field-initializers -Werror=pointer-arith
> -fPIC -DHAVE_LLVM=0x0207 -DDEBUG -
Submitted. Thanks.
Jose
On Tue, 2010-09-07 at 02:59 -0700, Tilman Sauerbeck wrote:
> That file has been replaced by tgsi.rst.
> ---
> src/gallium/include/pipe/p_shader_tokens.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/include/pipe/p_shader_token
FWIW, I think this is a worthwhile interface cleanup. Your commit
comment says it all.
I did think of this when introducing the current shader caps enums, but
informal feedback I got was that it was better to stick with the current
get_param system. Now that the number of shader types is growing p
Luca,
I think this is not a worthwhile change, at least not by itself.
First, this will cause the binary TGSI representation to change, and can
break some code which expects this particular ordering. For example, you
forgot to update tgsi_dump.c's processor_type_names[] array. And there
might be
On Wed, 2010-09-01 at 09:24 -0700, Luca Barbieri wrote:
> > It's an impressive amount of work you did here. I'll comment only on the
> > llvmpipe of the changes for now.
>
> Thanks for your feedback!
>
> > Admittedly, always using a floating point is not ideal. A better
> > solution would be to c
On Fri, 2010-08-27 at 05:49 -0700, Luca Barbieri wrote:
> I created a new branch called "floating" which includes an apparently
> successful attempt at full support of floating-point textures and
> render targets.
>
> I believe it is fundamentally correct, but should be considered a
> prototype an
On Sat, 2010-08-28 at 02:12 -0700, Dave Airlie wrote:
> Mostly we need this to remove a possible race on r300g, but I think
> it'll make implementing buffers on r600g easier as well.
>
> More explains in the patch.
>
> Dave.
Yes, an outcome of making transfers in-order context operations is that
It makes sense now. I think you should replace the comment in the code
with the paragraph you just wrote in your reply and then push it.
Jose
On Sun, 2010-08-29 at 07:55 -0700, Marek Olšák wrote:
> PIPE_CAP_MAX_FS_INPUTS specifies the number of COLORn + GENERICn
> inputs and is set in MaxNativeAt
On Sun, 2010-08-22 at 02:35 -0700, nobled wrote:
> The first three attached patches make it possible to compile Mesa with
> LLVM/Clang:
> 1. Add -lstdc++ when linking glsl_compiler and glcpp
> 2. Move -lstdc++ from the Gallium-specific Makefile.dri to
> DRI_LIB_DEPS in configure (fixes linking clas
1 - 100 of 181 matches
Mail list logo
