This looks good, and so does the rest of the series AFAICS.
Jose
- Original Message -
From: Brian Paul bri...@vmware.com
---
src/mesa/state_tracker/st_cb_texture.c | 62
src/mesa/state_tracker/st_extensions.c |1 +
2 files changed, 63
I only see implementation for ffvertex_prog.c
Wasn't (or will soon be) the FF-Mesa IR replaced with FF-GLSL IR? If so, can
you truly enable unconditionally on gallium/st?
Jose
- Original Message -
If there are no other concerns, I'll push this on Saturday, including
the nv20 fix
- Original Message -
From what I can see, the fog distance is computed per-vertex and
stored in the FogCoord vertex shader output. There is no fragment
shader change required. The fixed-function vertex program hasn't been
converted to the GLSL IR yet, only the fragment program, which
, Oct 24, 2011 at 5:37 PM, Jose Fonseca jfons...@vmware.com
wrote:
Looks good to me. Just a few minor requests:
- The APIENTRY keyword in stw_create_context_attribs() is
unnecessary given it is an internal API.
- Please move the stw_create_context_attribs() immediately after
- Original Message -
[...]
Anyway, you guys are doing it, and it doesn't seem like Keith or Brian have
an opinion, so as far as I'm concerned, feel free to decide among yourselves
and start coding away in a branch.
I only have two requirements:
- there must be no regression on
I've pushed, but it doesn't work on nvidia.
It fails with error 0xc0072096.
Have you tried with different implementations?
Jose
- Original Message -
---
src/wgl/CMakeLists.txt |1 +
src/wgl/wglcontext.c | 274
2 files
I haven't had the time to pay with the dir/swrast tfp yet, so I can't really
comment the technical details.
But, code de-duplication is always nice. So as long as there is no known
regressions introduced for this, I'm thumbs up.
Jose
- Original Message -
Hi,
[please cc: me in any
Hi Kristian,
I got this log from a build daemon:
[...truncated 3700 lines...]
dri2.c:716:4: error: unknown field ‘WaitForMSC’ specified in initializer
dri2.c:718:4: error: unknown field ‘SwapBuffers’ specified in initializer
dri2.c:718:4: warning: excess elements in struct initializer
- Original Message -
On Wed, Nov 2, 2011 at 11:43 AM, Jose Fonseca jfons...@vmware.com
wrote:
Hi Kristian,
Jose,
Sorry about that, I just pushed a commit to fix these issues.
Kristian
No prob. That's why build daemons are for. They are happy again now!
Jose
Looks good to me, Michel.
Jose
- Original Message -
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/auxiliary/util/u_math.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git
- Original Message -
The patch should be correctly formatted, but I attached it anyway to
be sure for this time.
Actually, it failed when I tried the apply the full mail:
$ git am -3 ~/tmp/patch.txt
Applying: wglSetPixelFormat should ignore the ppfd parameter
Using index info to
What about checking has_geometry_shader inside cso module, and make
cso_save_geometry_shader no-ops when it's false?
Seems less code and more reusable.
Jose
- Original Message -
The code expects the geometry shader to be NULL.
We don't have geometry shaders now, but it's good to be
Looks ok to me.
Jose
- Original Message -
---
src/gallium/auxiliary/cso_cache/cso_context.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c
b/src/gallium/auxiliary/cso_cache/cso_context.c
index
- Original Message -
The code expects the geometry shader to be NULL.
We don't have geometry shaders now, but it's good to be prepared.
v2: check for support in the cso context
---
src/gallium/auxiliary/cso_cache/cso_context.c | 17
-
Make sense. The same goes for PIPE_FORMAT_LATC1_SNORM and
PIPE_FORMAT_LATC1_SNORM I suppose.
Jose
- Original Message -
From: Dave Airlie airl...@redhat.com
Signed RGTC won't fit in a unorm, so don't allow them.
Signed-off-by: Dave Airlie airl...@redhat.com
---
Good catch! Thanks.
Jose
- Original Message -
From: Dave Airlie airl...@redhat.com
Just found by reading llvmpipe code for no great reason.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c |2 +-
1 files changed, 1
I have no objection.
The only thing that I know we could do to improve this situation is to factor
out the compiler/os/crt abstractions out of mesa/gallium/etc into a shared
library. I brought and been wanting to do this for a long time, but just
haven't been able to find opportunity (because
I'm not very familar with conditional rendering, but I don't see anything wrong
FWIW.
Jose
- Original Message -
From: Dave Airlie airl...@redhat.com
This ports the softpipe NV_conditional_render support to llvmpipe.
This passes the nv_conditional_render-* piglit tests.
Looks good AFAICT.
- Original Message -
From: Dave Airlie airl...@redhat.com
These two are fairly unique types so add specific cases for decoding
them.
Passes piglit fbo-clear-format and fbo-generatemipmap-format tests
for these
two extensions.
Signed-off-by: Dave Airlie
- Original Message -
From: Dave Airlie airl...@redhat.com
This adds timer query support, though I'm not 100% sure about the bin
stuff
if we have multiple queries in flight, maybe it needs a linked list,
suggestions
welcome.
I think that taking the time interval to the last
- Original Message -
On 11/08/2011 12:30 PM, Jose Fonseca wrote:
At the moment MSVC build's failing with the error
mesa.lib(uniform_query.obj) : error LNK2001: unresolved external
symbol int MESA_VERBOSE (?MESA_VERBOSE@@3HA)
build\windows-x86-debug\gallium\targets\libgl-gdi
Looks good Brian. The rest of the series looks good too AFAICT, although some
of the modules are a bit outside my familiarity zone.
Jose
- Original Message -
v2: check if pipe_buffer_map() returns NULL, and return NULL from
svga_vbuf_render_map_vertices(). Per Jose's suggestion.
---
- Original Message -
Am Freitag, 11. November 2011 14:33 CET, Michel Dänzer
mic...@daenzer.net schrieb:
On Fre, 2011-11-11 at 14:15 +0100, Theiss, Ingo wrote:
Am Freitag, 11. November 2011 12:09 CET, Michel Dänzer
mic...@daenzer.net schrieb:
So It makes sense to
- Original Message -
On 13.11.2011 17:32, Christoph Bumiller wrote:
On 13.11.2011 17:10, Marek Olšák wrote:
I am guessing there is no type info because TGSI shaders are
allowed
to use uint, sint, and float instructions on the same register
without
type conversions (it would
- Original Message -
- Original Message -
On 13.11.2011 17:32, Christoph Bumiller wrote:
On 13.11.2011 17:10, Marek Olšák wrote:
I am guessing there is no type info because TGSI shaders are
allowed
to use uint, sint, and float instructions on the same register
Looks good, but some warnings on util_draw_max_index would be useful, as this
is not something apps normally do, so are much more often a symptom of a state
tracker bug than apps bugs.
Jose
- Original Message -
Don't assert/die if a VBO is too small. Return zero instead.
Note that
- Original Message -
On 14.11.2011 11:33, Jose Fonseca wrote:
- Original Message -
On 13.11.2011 17:32, Christoph Bumiller wrote:
On 13.11.2011 17:10, Marek Olšák wrote:
I am guessing there is no type info because TGSI shaders are
allowed
to use uint, sint
- Original Message -
On 14.11.2011 12:28, Jose Fonseca wrote:
- Original Message -
Indirect addressing on TEMP should be forbidden and only allowed
for
TEMPORARY_ARRAY, I'd very much like to know which values I can
keep
in
registers and which ones I have to store
Looks good to me.
Jose
- Original Message -
Broken by addition of SYSTEM_VALUE_VERTEX_ID in
919c53e87a1f6f5322bc1f1486bb3e6b954b00d5.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |1 +
src/mesa/state_tracker/st_mesa_to_tgsi.c |1 +
2 files changed, 2 insertions(+), 0
- Original Message -
On 12.11.2011 00:30, Brian Paul wrote:
On 11/11/2011 04:18 PM, Christoph Bumiller wrote:
On 11.11.2011 23:59, Brian Paul wrote:
On 11/11/2011 03:18 PM, Christoph Bumiller wrote:
---
src/gallium/auxiliary/tgsi/tgsi_dump.c |1 +
Is it really necessary to bother pipe drivers with zero size buffers?
It looks like a useless corner case, which will cause all sort of
implementations problems (e.g., malloc(0) may return NULL; kernel drivers will
likely refuse 0 size buffers), so pipe drivers will need a lot of
if
That's verbose enough thanks.
BTW, just noticed another problem in the change, the line
max_index = ~0;
should be replaced with
max_index = ~0U - 1;
otherwise
return max_index + 1;
will overflow and return 0 when all elements have stride 0, or are
per-instance, causing the draw to
- Original Message -
The next open question I have is whether this warrants additions to
the tgsi_opcode_info struct, mainly whether the return value is
uint/int/float,
and whether then src regs are uint/int/float, I'm not 100% that all
opcodes always take all int/uint/float srcs,
- Original Message -
- Original Message -
The next open question I have is whether this warrants additions to
the tgsi_opcode_info struct, mainly whether the return value is
uint/int/float,
and whether then src regs are uint/int/float, I'm not 100% that all
opcodes
- Original Message -
On 11/14/2011 08:23 PM, Jose Fonseca wrote:
- Original Message -
The next open question I have is whether this warrants additions
to
the tgsi_opcode_info struct, mainly whether the return value is
uint/int/float,
and whether then src regs
- Original Message -
On 11/14/2011 09:24 PM, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 08:23 PM, Jose Fonseca wrote:
- Original Message -
The next open question I have is whether this warrants additions
to
the tgsi_opcode_info struct
- Original Message -
On 11/14/2011 09:48 PM, Christoph Bumiller wrote:
On 11/14/2011 09:24 PM, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 08:23 PM, Jose Fonseca wrote:
- Original Message -
The next open question I have is whether
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM, Vadim
Girlinvadimgir...@gmail.com wrote:
On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote:
- Original Message -
Hi,
I found some problem with glsl_to_tgsi
- Original Message -
On 11/13/2011 03:06 AM, Vadim Girlin wrote:
Hi,
I found some problem with glsl_to_tgsi: remove_output_reads
function.
It's replacing outputs with temps, producing incorrect results with
relative addressing. You can see it e.g. with
- Original Message -
On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
On 11/13/2011 03:06 AM, Vadim Girlin wrote:
Hi,
I found some problem with glsl_to_tgsi: remove_output_reads
function.
It's replacing outputs
- Original Message -
On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM, Vadim
Girlinvadimgir...@gmail.com wrote:
On Mon, 2011-11-14 at 05:22 -0800, Jose
Neither DX9 or DX10 expose equivalent to GL_RGB16F_ARB:
- http://msdn.microsoft.com/en-us/library/bb172558.aspx (D3D9)
- http://msdn.microsoft.com/en-us/library/bb173059.aspx (D3D10)
So probably no hardware ever will support them.
Even for software rendering it is a very nasty format to support,
- Original Message -
On 11/14/2011 10:13 PM, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 09:48 PM, Christoph Bumiller wrote:
On 11/14/2011 09:24 PM, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 08:23 PM, Jose Fonseca wrote
Looks good Brian.
BTW, we should probably be more defensive about map failures on this code. This
is not a regression, as st_cb_readpixels.c also did a poor job.
Jose
- Original Message -
In slow_read_depth_stencil_pixels_separate() we might have separate
depth and stencil buffers or
- Original Message -
Previously we were mapping/unmapping the index buffer each time we
found the restart index in the buffer. This is bad when the restart
index is frequently used. Now just map the index buffer once, scan
it to produce a list of sub-primitives, unmap the buffer,
I think that PIPE_CAP_FLOAT_XXX is too long and that the non-abbreviated
_FLOAT_ word is distracting and misleading, as it sounds like it's related with
floating point features, which is not. Something more subtle, such as
PIPE_CAPF_XXX, would be OK though. It's consistent with get_param and
Johannes Obermayr's recent patch series remind me of one thing I've been
planning to ask here for quite some time:
Would anybody oppose dropping automake build system in mesademos for just cmake
?
On Mesa there is rationale behind the two different build systems (automake and
scons), but for
Looks good to me.
Jose
- Original Message -
---
src/mesa/main/readpix.c | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index aa893de..8048a72 100644
---
- Original Message -
On Mon, Nov 21, 2011 at 11:17 AM, Jose Fonseca jfons...@vmware.com
wrote:
Johannes Obermayr's recent patch series remind me of one thing I've
been planning to ask here for quite some time:
Would anybody oppose dropping automake build system in mesademos
- Original Message -
On 11/21/2011 09:40 AM, Eric Anholt wrote:
On Mon, 21 Nov 2011 03:17:03 -0800 (PST), Jose Fonseca
jfons...@vmware.com wrote:
Johannes Obermayr's recent patch series remind me of one thing
I've
been planning to ask here for quite some time:
Would
- Original Message -
On Mon, 21 Nov 2011 03:17:03 -0800 (PST), Jose Fonseca
jfons...@vmware.com wrote:
Johannes Obermayr's recent patch series remind me of one thing I've
been planning to ask here for quite some time:
Would anybody oppose dropping automake build system
- Original Message -
If the gallium driver doesn't support PIPE_FORMAT_R16G16B16A16_SNORM
the call to st_choose_renderbuffer_format() would fail and we'd
generate
an GL_OUT_OF_MEMORY error. We'd never get to the subsequent code
that
handles software/malloc-based renderbuffers.
- Original Message -
NAK with extreme prejudice. Technically speaking, these are app
bugs.
I absolutely will not disable all correct behavior to work around
broken
apps. The problem is the following shaders will correctly link, but
completely explode:
uniform float array[1234];
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface changes:
- e.g., provide to GLSL compiler infinite/huge limits, while advertising to
the app the pipe driver ones
- or detect the wine process and advertise bigger limits in
- Original Message -
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca jfons...@vmware.com
wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface
changes:
- e.g., provide to GLSL compiler infinite/huge limits
Determining software rendering by the string is unreliable.
And the glXIsDirect just duplicates information listed before.
Furthermore, printing these warnings to stdout would be a very bad idea --
scripts which run glxinfo and parse could easily get confused by these messages.
Overall, I
glxgears is a benchmark, just doesn't benchmark what people often expect. I
often use it as a present/swapbuffers benchmark. So the whole blurb about not
using glxgears as a benchmark is false.
Again, detecting software rendering by the string is unreliable.
Maybe it help if you could provide
Looks good.
Jose
- Original Message -
---
src/egl/eglut/CMakeLists.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/egl/eglut/CMakeLists.txt
b/src/egl/eglut/CMakeLists.txt
index b97caa6..45208d6 100644
--- a/src/egl/eglut/CMakeLists.txt
+++
Looks good to me.
Jose
- Original Message -
---
CMakeLists.txt |4
src/egl/eglut/CMakeLists.txt |6 ++
src/util/CMakeLists.txt |4
src/xdemos/CMakeLists.txt|4
4 files changed, 18 insertions(+), 0 deletions(-)
diff --git
Looks good to me FWIW.
But it might be worth to wait a little more for somebody familiar with autoconf
to review that part well.
Jose
- Original Message -
It introduces following variables (as prefixes):
(-D)BINDIR - default: none, ${BINDIR}/${subdir}
(-D)DATADIR - default:
- Original Message -
While Ian and I may take a more idealist stance (favoring strict
compliance), and you perhaps a more pragmatic view (get more apps
running), we're all working toward the same goal: to build great
OpenGL
drivers and advance the state of the art for open source 3D
- Original Message -
People are being more honest on
IRC than here.
I read some of the IRC logs from the past days, and there were several
saddening statements made in there by several people.
But I wonder if IRC does really bring the most honest side out of people, or
simply their
- Original Message -
And warn loudly in case people want to use it. Too many tester report
gpu hangs on irc and we rootcause this ...
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
If you're doing this then why not just remove the drive all together, as agreed
a few days ago?
Brian,
The whole series looks a nice cleanup to me.
I haven't tried to compile this on MSVC, but it looks ordinary C, so it should
be alright.
Jose
- Original Message -
This can be used to check that tables have the right number of
entries,
etc. at compile-time. This will
The bulk is there but there are a few places missing.
I'll update those, do some sanity checks and commit.
Jose
- Original Message -
Dear mesa-dev list,
Kai Wasserbäch schrieb am 29.11.2011 15:17:
Kai Wasserbäch (1):
i965g: Delete this driver, it is broken.
the patch itself
- Original Message -
On Tue, Nov 29, 2011 at 10:12 AM, Jose Fonseca jfons...@vmware.com
wrote:
The bulk is there but there are a few places missing.
I'll update those, do some sanity checks and commit.
Jose
Is there a good reason to delete i965g ?
Hi Jerome,
Yes. Please
Thanks. This one was was almost perfect -- it was just missing to remove
src/gallium/auxiliary/rtasm/rtasm_ppc_spe.[ch] which was only used by cell.
I'll push later if there are no objections.
Jose
- Original Message -
Dear mesa-dev list,
the recent discussion about enabling GLSL
It looks like there is a regression,
https://bugs.freedesktop.org/show_bug.cgi?id=43353 . Can you investigate this?
Jose
- Original Message -
Hi,
Apologies for braking this!
Thanks, looks great.
Mathias
On Tuesday, November 29, 2011 08:22:58 Chia-I Wu wrote:
From: Chia-I
- Original Message -
On 11/30/2011 09:10 PM, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
This fixes the firefox crash but I've no idea if its correct.
I don't think it is.
Visual.samples is the value passed to RenderbufferStorageMultisample,
and 1 here means a
Brian,
The series looks good.
BTW, this just remind be of one thing I noticed looking at coverity results
before is that it is almost impossible to get zero warnings everywhere. For
example, gcc complains that a variable may be used unitialized (when often it
cannot), and setting an initial
Looks good to me.
Jose
- Original Message -
Hi,
Attached is a change to the ARB program parser that should fix
https://bugs.freedesktop.org/show_bug.cgi?id=43407
Please review.
Thanks
Mathias
___
mesa-dev mailing list
- Original Message -
Implemented in terms of renderbuffer mapping/unmapping and format
packing/unpacking functions.
The swrast and state tracker code for implementing accumulation are
unused and will be removed in the next commit.
v2: don't use memcpy() in
- Original Message -
On 11/19/2011 09:44 PM, Marek Olšák wrote:
Hi everyone,
this patch series implements all the core Mesa and Gallium support
for EXT_transform_feedback and ARB_transform_feedback2. It's been
tested by me on Radeons and by Christoph Bumiller on Nouveau. I
I suppose that 16 is enough because Mesa always uses floats as intermediates
(and never doubles), right?
Either way is a good cleanup.
Jose
- Original Message -
In a few places we need to allocate space for some number of generic
pixels. Use this new define instead of a magic number
And the rest of the series looks good to me too.
Jose
- Original Message -
I suppose that 16 is enough because Mesa always uses floats as
intermediates (and never doubles), right?
Either way is a good cleanup.
Jose
- Original Message -
In a few places we need to
- Original Message -
On 12/05/2011 08:02 PM, Jose Fonseca wrote:
- Original Message -
On 11/19/2011 09:44 PM, Marek Olšák wrote:
Hi everyone,
this patch series implements all the core Mesa and Gallium
support
for EXT_transform_feedback
I wrote a testsuite for apitrace, and one of the tests checks the default GL
state against a reference, and it is failing on all Gallium DRI drivers because
{
parameters: {
GL_DRAW_BUFFER: GL_BACK - GL_BACK_LEFT,
GL_DRAW_BUFFER0: GL_BACK - GL_BACK_LEFT,
GL_READ_BUFFER: GL_BACK -
- Original Message -
I wrote a testsuite for apitrace, and one of the tests checks the
default GL state against a reference, and it is failing on all
Gallium DRI drivers because
{
parameters: {
GL_DRAW_BUFFER: GL_BACK - GL_BACK_LEFT,
GL_DRAW_BUFFER0: GL_BACK -
- Original Message -
On Fri, Dec 9, 2011 at 2:02 PM, Chia-I Wu o...@lunarg.com wrote:
On Thu, Dec 8, 2011 at 10:00 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
It sets the wrong values (GL_XXX_LEFT instead of GL_XXX), and no
other
Mesa driver does
- Original Message -
On 12/09/2011 07:00 AM, nobled wrote:
The VERT_BIT_* defines are 64-bit values since commit
f364ac1da10ff67eba5196c1074aff579864f741, but the printf
was still expecting a simple int. This worked on little-endian
hosts because the values were still less than
- Original Message -
On 12/09/2011 07:59 AM, Jose Fonseca wrote:
- Original Message -
On 12/09/2011 07:00 AM, nobled wrote:
The VERT_BIT_* defines are 64-bit values since commit
f364ac1da10ff67eba5196c1074aff579864f741, but the printf
was still expecting a simple int
- Original Message -
On 12/09/2011 01:58 AM, Jose Fonseca wrote:
- Original Message -
On Fri, Dec 9, 2011 at 2:02 PM, Chia-I Wuo...@lunarg.com wrote:
On Thu, Dec 8, 2011 at 10:00 PM,jfons...@vmware.com wrote:
From: José Fonsecajfons...@vmware.com
It sets the wrong
- Original Message -
Dear mesa-dev list,
Kai Wasserbäch schrieb am 09.12.2011 12:59:
AFAICS GCC was missed from the last #elif clause. With this patch
applied the warning is gone.
Signed-off-by: Kai Wasserbäch k...@dev.carbon-project.org
---
There certainly other warnings
I saw this email yesterday, but did not have time to reply.
- Original Message -
On Mon, Nov 21, 2011 at 6:52 PM, Eric Anholt e...@anholt.net wrote:
On Sun, 20 Nov 2011 15:08:55 +0100, Marek Olšák mar...@gmail.com
wrote:
unpack_float_z_Z24_X8 fails with -O2 in:
- fbo-blit-d24s8
- Original Message -
On Mon, Dec 12, 2011 at 1:24 PM, Jose Fonseca jfons...@vmware.com
wrote:
I saw this email yesterday, but did not have time to reply.
- Original Message -
On Mon, Nov 21, 2011 at 6:52 PM, Eric Anholt e...@anholt.net
wrote:
On Sun, 20 Nov 2011 15
) {
It should be state-stream_output.num_outputs IIUC.
Other than that,
Reviewed-By: Jose Fonseca jfons...@vmware.com
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
- Original Message -
From: Marek Olšák mar...@gmail.com
It's like DrawArrays, but the count is taken from a transform
feedback
object.
This removes DrawTransformFeedback from dd_function_table and adds
the same
function to GLvertexformat (with the function parameters matching
- Original Message -
Hi,
I have just pushed a branch containing an LLVM shader backend for
r600g to my
personal git repo:
http://cgit.freedesktop.org/~tstellar/mesa/ r600g-llvm-shader
Hi Tom,
This is pretty cool stuff. The fact that you have a similar passing rate to
the
- Original Message -
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 12
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 14
--
2 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
- Original Message -
On Mon, Dec 12, 2011 at 2:10 PM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
On Mon, Dec 12, 2011 at 1:24 PM, Jose Fonseca
jfons...@vmware.com
wrote:
I saw this email yesterday, but did not have time to reply
- Original Message -
On Mon, Dec 12, 2011 at 8:20 AM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
On Mon, Dec 12, 2011 at 2:10 PM, Jose Fonseca
jfons...@vmware.com
wrote:
- Original Message -
On Mon, Dec 12, 2011 at 1:24 PM, Jose
- Original Message -
On 12/12/2011 02:49 PM, Jose Fonseca wrote:
- Original Message -
From: Marek Olšák mar...@gmail.com
It's like DrawArrays, but the count is taken from a transform
feedback
object.
This removes DrawTransformFeedback from dd_function_table
- Original Message -
This is an updated version of the patch set I sent to the list a few
hours
ago.
There is now a TGSI property called
TGSI_PROPERTY_NUM_CLIP_DISTANCES
that drivers can use to determine how many of the 8 available clip
distances
are actually used by a
- Original Message -
- Original Message -
On 12/13/2011 09:11 PM, Jose Fonseca wrote:
- Original Message -
This is an updated version of the patch set I sent to the list a
few
hours
ago.
There is now a TGSI property called
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan Cain wrote:
On 12/13/2011 02:11 PM, Jose Fonseca wrote:
- Original Message -
This is an updated version of the patch set I sent to the list
- Original Message -
On 12/13/2011 03:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan Cain wrote:
On 12/13/2011 02:11 PM, Jose Fonseca wrote:
- Original Message
- Original Message -
On 12/13/2011 03:48 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan Cain
- Original Message -
On 12/13/2011 03:48 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan Cain
- Original Message -
- Original Message -
On 12/13/2011 03:48 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message
- Original Message -
On 12/14/2011 12:58 AM, Ian Romanick wrote:
On 12/13/2011 01:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan Cain wrote:
On 12/13/2011 02
1 - 100 of 2262 matches
Mail list logo
