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
(Switching from dead mesa3d-...@sf.net - mesa-...@fdo.org ML)
On Thu, Jan 17, 2013 at 11:23 PM, Sedat Dilek sedat.di...@gmail.com 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:
apitrace/gallium question..
On Mon, Jun 3, 2013 at 11:56 AM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Mon, Jun 3, 2013 at 10:41 AM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
On Fri, May 31, 2013 at 10:18 AM, José Fonseca
On Tue, Mar 5, 2013 at 9:11 AM, Alexander Monakov amona...@ispras.ruwrote:
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
On Sat, Jun 15, 2013 at 8:05 PM, Carl Worth cwo...@cworth.org wrote:
José Fonseca jfons...@vmware.com writes:
FYI, with
https://github.com/apitrace/apitrace/commit/7700f74f294a28e57860487b917c8807156b3ad1
apitrace no longer crashes with Steam overlay.
Thanks, José! This will be quite
On Tue, 2010-04-13 at 00:55 -0700, Dave Airlie wrote:
No offence to gallium, but I don't think its been mature enough to
ship a driver for as long as Intel have had to ship drivers. I'm not
even sure its mature enough to ship a driver with yet. I know you guys
have shipped drivers using it,
Author: José Fonseca jfons...@vmware.com
Date: Sat Apr 10 02:44:52 2010 +0100
scons: Make debug build default.
I've been back and forth on this, but I believe it's worth to have debug
by default.
Most humans (developers, testers) will want to use the debug version
On Mon, 2010-04-19 at 06:22 -0700, Keith Whitwell wrote:
On Mon, 2010-04-19 at 06:07 -0700, Marek Olšák wrote:
Unfortunately, this is supported only on r500 (i.e. not r300 nor r400)
and only when the DRM version is =2.3.0 (i.e. kernel 2.6.34). Please,
can we make it an optional feature?
On Mon, 2010-04-19 at 11:16 -0700, Keith Whitwell wrote:
On Mon, 2010-04-19 at 09:49 -0700, José Fonseca wrote:
On Mon, 2010-04-19 at 06:22 -0700, Keith Whitwell wrote:
On Mon, 2010-04-19 at 06:07 -0700, Marek Olšák wrote:
Unfortunately, this is supported only on r500 (i.e. not r300 nor
On Thu, 2010-04-22 at 14:28 -0700, Jakob Bornecrantz wrote:
Hi José et al
So I got a bit annoyed at seeing the debug_get_*_option print outs
every single time it checks the value.
The first patch just adds another option to control if we print the
options or not.
The second adds helper
Hi Roland,
Overall looks good. It's nice to finally have a way to export MSAA
capabilities, and see the pipe_surfaces use being more constrained.
A few comments inline, but no strong feelings so feel free to do as you
wish.
Jose
On Mon, 2010-04-26 at 11:05 -0700, Roland Scheidegger wrote:
On Tue, 2010-04-27 at 08:59 -0700, Roland Scheidegger wrote:
On 27.04.2010 17:32, Roland Scheidegger wrote:
On 27.04.2010 13:13, Dave Airlie wrote:
Another trying to figure out gallium patch from me,
This is in theory EXT_texture_swizzle support, r300g passes the glean
test with this
We don't have such fined grain capabilities in Gallium drivers yet, so I
followed Keith's suggestion of tie the native program limits to the GLSL
and SM3 support exported by the driver.
I'm selling this as a short term fix. I think we should start thinking
in shader caps in gallium, and how fine
On Sun, 2010-05-02 at 00:42 -0700, Dave Airlie wrote:
So playing with swizzle found this bug in softpipe, I just wonder if
the is_compat_view check needs further expansion or have I done
enough?
At least this one
tc-format == view-format
should be added. The rest appears to be handled
Hi Kristian,
Most of the mesa builds (make and scons) got broken with this merge due
to missing *_remap_index symbols in remap_helper.h
I took a look but it's not obvious to me how to fix it.
Jose
gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
On Thu, 2010-04-29 at 09:50 -0700, Karl Schultz wrote:
On Thu, Apr 29, 2010 at 9:54 AM, Brian Paul bri...@vmware.com wrote:
Was: Merging GLES1/2 to mesa/main
Chia-I Wu wrote:
2010/4/29 Kristian Høgsberg k...@bitplanet.net:
On Mon, 2010-05-03 at 09:44 -0700, Brian Paul wrote:
Jose Fonseca wrote:
I read the extension and it is not crystal clear, but it seems to imply the
swizzles are orthogonal to the format, and applied as the very last step
before being used in a shader. That is, the semantics are the same
On Mon, 2010-05-03 at 10:25 -0700, Marek Olšák wrote:
José,
the first patch removes the PIPE_FORMAT_ prefix in a string returned
by util_format_name, it makes debug logs shorter. The second patch
adds util_format_is_plain.
diff --git a/src/gallium/auxiliary/util/u_format.h
On Mon, 2010-05-03 at 10:29 -0700, José Fonseca wrote:
On Mon, 2010-05-03 at 09:44 -0700, Brian Paul wrote:
Jose Fonseca wrote:
I read the extension and it is not crystal clear, but it seems to imply
the swizzles are orthogonal to the format, and applied as the very last
step before
On Mon, 2010-05-03 at 10:42 -0700, Brian Paul wrote:
Marek Olšák wrote:
José,
the first patch removes the PIPE_FORMAT_ prefix in a string returned by
util_format_name, it makes debug logs shorter. The second patch adds
util_format_is_plain.
I'd prefer to keep the long format
On Sun, 2010-04-25 at 09:50 -0700, José Fonseca wrote:
Now that transfers are context operations it is the driver's
responsibility to ensure that transfers happen in order with all other
context operations, so flushes and finishes inside Mesa should be no
longer necessary. The attached patch
On Tue, 2010-05-11 at 06:38 -0700, Jakob Bornecrantz wrote:
On 2010-05-11 11.49, José Fonseca wrote:
Attached is my proposal for fine grained caps for shader limits.
These don't cover which opcodes are supported, so PIPE_CAP_GLSL and
PIPE_CAP_SM3 remains. I think that PIPE_CAP_SM3 should
On Fri, 2010-05-21 at 07:45 -0700, Keith Whitwell wrote:
On Wed, 2010-05-19 at 05:29 -0700, Keith Whitwell wrote:
So, the front vs. ccw feature branch is working pretty well for softpipe
and llvmpipe.
I've got some documentation fixup to do, but it would also be good if
the various
On Tue, 2010-05-18 at 10:04 -0700, Roland Scheidegger wrote:
Hi,
I plan to merge the gallium-msaa branch to master soon.
It's actually a bit of a misnomer since the conceptually more important
changes in there are about blits...
Here's a short summary what this is about:
blits now
On Wed, 2010-06-02 at 17:15 -0700, Brian Paul wrote:
If there's no concerns, I'll commit this tomorrow.
-Brian
Looks good to me Brian. Thanks.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote:
Jakob Bornecrantz wrote:
On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz wallbra...@gmail.com
wrote:
Since we don't have any progs in mesa that uses glew anymore is it
okay if we drop it? I have attached a patch which drops it its a
The patch looks good, but we don't support pipe_condvar on Windows yet.
I'd prefer to see the commit deferred until we do.
Any takers to implement pipe_condvar on Windows? There's even a nice
tutorial on http://locklessinc.com/articles/pthreads_on_windows/
Jose
On Mon, 2010-07-05 at 09:53
does right now on
Unix-- unlock the mutex, wait for other threads, then try to lock it
again. pipe_condvar on Windows (or any other platform) will *work*, it
just won't be very efficient.
On Tue, Jul 6, 2010 at 6:46 AM, José Fonseca jfons...@vmware.com wrote:
The patch looks good, but we
On Sun, 2010-07-25 at 19:09 -0700, Jakob Bornecrantz wrote:
On Sun, Jul 25, 2010 at 3:25 PM, nobled nob...@dreamwidth.org wrote:
Attached several small patches; review appreciated.
1. i915g: fix llvm build (typo)
2. st/xorg: fix use-after-free
5. fix copy/paste error in the debug output
On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote:
As everyone knows, a group of us at Intel have been rewriting Mesa's
GLSL compiler. The work started out-of-tree as a stand alone compiler.
We moved all of our work to the glsl2 branch in the Mesa tree as soon
as we had some actual code
On Sun, 2010-08-01 at 10:19 -0700, Eric Anholt wrote:
On Tue, 27 Jul 2010 21:32:57 +0100, José Fonseca jfons...@vmware.com wrote:
On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote:
As everyone knows, a group of us at Intel have been rewriting Mesa's
GLSL compiler. The work started
On Tue, 2010-08-10 at 22:57 -0700, Aras Pranckevicius wrote:
No, it's missing most of the API that talloc provides.
Also,
http://github.com/aras-p/glsl-optimizer/ ported it to
windows.
Could then Aras Pranckevicius's talloc port to windows be
On Wed, 2010-08-11 at 07:59 -0700, Luca Barbieri wrote:
I assumed that the fact it would crash on a debug build would make the
behavior safe to change.
Even if it doesn't crash, it is anyway working incorrectly.
Assert failures mean something that developers didn't anticipate to
happen did
On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
Could then Aras Pranckevicius's talloc port to windows be merged into
glsl2 branch before glsl2 is merged into master?
I think we learned our lesson with GLEW
On Wed, 2010-08-11 at 13:18 -0700, Aras Pranckevicius wrote:
Could then Aras Pranckevicius's talloc port to windows be
merged into
glsl2 branch before glsl2 is merged into master?
I think we learned our lesson with GLEW. Trying to keep a
On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote:
On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca jfons...@vmware.com wrote:
On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
Could then Aras Pranckevicius's
On Thu, 2010-08-12 at 04:10 -0700, Dave Airlie wrote:
On Thu, Aug 12, 2010 at 9:00 PM, José Fonseca jfons...@vmware.com wrote:
On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote:
On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca jfons...@vmware.com wrote:
On Wed, 2010-08-11 at 12:52 -0700
On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote:
On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com wrote:
Really optimising for the wrong bunch of people here by dragging this
stuff into mesa git.
Many projects do this: they include the source of other projects
On Thu, 2010-08-12 at 08:33 -0700, Matt Turner wrote:
On Thu, Aug 12, 2010 at 11:27 AM, José Fonseca jfons...@vmware.com wrote:
On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote:
On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com wrote:
Really optimising for the wrong
On Thu, 2010-08-12 at 14:46 -0700, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
OK.
What about this:
For GLUT, GLEW, LLVM and all other dependencies I'll just make a SDK
with the binaries, with debug release, 32 64 bit, MinGW MSVC
On Fri, 2010-08-13 at 06:47 -0700, Luca Barbieri wrote:
A few related changes:
1. Make x86-64 its own architecture (nothing was using so
util_cpu_caps.arch, so nothing can be affected)
Just remove util_cpu_caps.arch. It's there simply due to its historical
ancestry. We have PIPE_ARCH
Luca,
This is great stuff.
But one request: if Win64 is untested, please make sure it is disabled
by default until somebody had opportunity to test it. Unfortunately I'm
really busy with other stuff ATM and don't have the time.
Jose
On Fri, 2010-08-13 at 06:47 -0700, Luca Barbieri wrote:
On Fri, 2010-08-13 at 21:41 +0100, José Fonseca wrote:
On Fri, 2010-08-13 at 06:47 -0700, Luca Barbieri wrote:
A few related changes:
1. Make x86-64 its own architecture (nothing was using so
util_cpu_caps.arch, so nothing can be affected)
Just remove util_cpu_caps.arch. It's
On Sun, 2010-08-15 at 09:22 -0700, tom fogal wrote:
Luca Barbieri l...@luca-barbieri.com writes:
I just discovered that Microsoft wisely decided to use their own
calling convention on Win64...
Yep.
This hasn't actually been tested on Win64 though.
Does mingw or cygwin support win64? I
On Fri, 2010-08-13 at 20:40 -0700, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
I propose that we merge master to glsl2 on *Friday, August 13th* (one
week from today). Barring unforeseen issues, I propose that we merge
glsl2 to master on
On Mon, 2010-08-16 at 10:30 -0700, nobled wrote:
I think this might be the problem that kept -disable-mmx from working;
can somebody test it? (attached)
@@ -152,15 +151,13 @@ lp_set_target_options(void)
* See also:
* - http://llvm.org/bugs/show_bug.cgi?id=3287
* -
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 classic
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
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 and
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 choose a
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
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
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_tokens.h
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
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 wallbra...@gmail.com
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
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 til...@code-monkey.de
---
The same fix needs to be
On Tue, 2010-09-21 at 05:00 -0700, Henri Verbeet wrote:
On 21 September 2010 13:13, Luca Barbieri l...@luca-barbieri.com 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
On Tue, 2010-09-21 at 02:14 -0700, Jakob Bornecrantz wrote:
On Tue, Sep 21, 2010 at 10:42 AM, Keith Whitwell kei...@vmware.com 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
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 environment.
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 tfo...@sci.utah.edu 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
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 again to
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 fragment
+verts[21] = 1.0 # g3
+verts[22] = 0.6 # b3
verts[23] = 1.0 # a3
ctx.draw_vertices(PIPE_PRIM_TRIANGLES,
On Wed, Sep 29, 2010 at 10:57 AM, José Fonseca jfons...@vmware.com wrote:
Could you please send me the modified tri.py as well. Thanks
Jose
On Wed, 2010-09-29
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.
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 is specified, which is only specified
On Mon, 2010-10-18 at 10:52 -0700, Keith Whitwell wrote:
On Mon, Oct 18, 2010 at 9:18 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Fri, Oct 15, 2010 at 7:44 PM, John Kessenich jo...@lunarg.com wrote:
Hi,
LunarG has decided to work on an open source, long-term, highly-functional,
and
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
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 mic...@vmware.com
Date: Thu, 4 Nov 2010 17:29:01 +0100
Subject: [PATCH] os: Allow file
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 XML output of trace. Though I think we should
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
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
On Wed, 2010-11-10 at 13:24 -0800, Marek Olšák wrote:
On Wed, Nov 10, 2010 at 9:48 PM, José Fonseca
jfons...@vmware.commailto: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 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-components(); c++) {
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
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
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
On Fri, 2010-12-03 at 15:37 -0800, Carl Worth wrote:
On Fri, 3 Dec 2010 13:34:09 -0800, Kenneth Graunke kenn...@whitecape.org
wrote:
On Friday 03 December 2010 08:01:06 José Fonseca wrote:
parser-space_tokens = 1;
statement conditional_tokens stanza -- it causes space tokens
On Mon, 2010-12-06 at 23:27 -0800, tom fogal wrote:
Jose Fonseca jfons...@vmware.com 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
On Mon, 2010-12-06 at 17:10 -0800, Carl Worth wrote:
On Mon, 06 Dec 2010 20:23:52 +, José Fonseca jfons...@vmware.com wrote:
I suppose it is possible for space to be significant on a conditional
expression, e.g.,
#if foo ()
vs
#if foo
There's no significant
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
Commited. Thanks.
Jose
On Thu, 2011-01-06 at 11:58 -0800, kristof.ralov...@gmail.com wrote:
On 2011-01-04, José Fonseca jfons...@vmware.com wrote:
Kristof,
It looks good overall with the exception that the build will fail if the
EGL library is not available.
Please guard the egl
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
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,
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
On Sat, 2011-01-22 at 19:18 -0800, Chad Versace wrote:
On Sat, Jan 22, 2011 at 17:46, Ian Romanick i...@freedesktop.org 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
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 commit
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é Fonseca jfons...@vmware.com:
D3D9 API limits the blits to/from depth-stencil buffers as well
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
On Sun, Mar 11, 2012 at 6:59 PM, Dave Airlie airl...@gmail.com wrote:
(resend to include list, I only sent it to Jose by accident).
On Fri, Mar 9, 2012 at 8:22 PM, José Fonseca jose.r.fons...@gmail.com wrote:
There are several new features in apitrace that deserve an announcement:
I had
On Sun, Mar 11, 2012 at 7:00 PM, José Fonseca jose.r.fons...@gmail.com wrote:
On Sun, Mar 11, 2012 at 6:59 PM, Dave Airlie airl...@gmail.com wrote:
(resend to include list, I only sent it to Jose by accident).
On Fri, Mar 9, 2012 at 8:22 PM, José Fonseca jose.r.fons...@gmail.com
wrote
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
Author:
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 buffers
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 might use
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, Benoit Jacob
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
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
On Wed, 2011-02-09 at 17:55 -0800, Dave Airlie wrote:
On Thu, Feb 10, 2011 at 11:27 AM, Marek Olšák mar...@gmail.com 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.
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 mar...@gmail.com wrote:
In this case, we always use the corresponding linear format
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;
- map = pb_map(buf-buffer,
1 - 100 of 125 matches
Mail list logo
