Series looks alright AFAICT.
Jose
- Original Message -
> We weren't looping over all the slices in the array. The updated
> code should also correctly handle 3D compressed textures too, whenever
> we have that feature.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850
>
Looks good. Thanks.
Jose
- Original Message -
> vertex id has to be unaffected by the start index (i.e. when calling
> draw arrays with start_index = 5, the first vertex_id has to still
> be 0, not 5) and it has to be equal to the index when performing
> indexed rendering (in which case i
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
D3D10 specifies equation 2.3 (and I'm sure so that D3D9). So probably all
hardware can handle it.
I'm surprised that formula 2.2 even exists, and that OpenGL could have been so
lax about it.
Jose
- Original Message -
> Hello all,
>
> I've been looking at https://bugs.freedesktop.org/s
> GLenum target,
>}
> } /* loop over mipmap levels */
>
> +end:
> free(temp_src);
> free(temp_dst);
> free(temp_src_slices);
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Series looks good to me.
You should add a mention of this in src/gallium/docs/source/tgsi.rst too as it
is not an obvious feature.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Same as for gallivm (though these don't quite work correctly in softpipe,
> so untested).
> ---
>
Series looks alright AFAICT.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Just like the UNORM case we need to use round to nearest, not trunc.
> (There's also another problem, we're using the formula for SNORM->float
> which will produce a value below -1.0 for the most negat
- Original Message -
> > From: Roland Scheidegger
> >
> > llvm shifts are undefined for shift counts exceeding (or matching) bit
> > width,
> > so need to apply a mask for the tgsi shift instructions.
> >
> > v2: only use mask for the tgsi shift instructions, not for the build shift
>
LE_POS)
> OP12(SAMPLE_INFO)
>
> +OP13(UCMP)
> +
>
> #undef OP00
> #undef OP01
> --
> 1.7.10.4
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
- Original Message -
> On Tue, Jul 30, 2013 at 8:46 PM, Paul Berry wrote:
> > On 29 July 2013 11:09, Zack Rusin wrote:
> >>
> >> That looks wrong to me. We already account for the "other fields" in the
> >> vertex_size.
> >
> >
> > This patch came from Bryan Cain's original geometry shade
ldFSub(builder, a0_0f,
> + lp_build_const_float(gallivm, 0.5),
> + "");
> + LLVMValueRef a0 = vec4f(gallivm, face_val, zero, zero, zero, "facing");
> LLVMValueRef zerovec = vec4f_from_scalar(gallivm
- Original Message -
> > > + if (draw_will_inject_frontface(lp_context->draw) &&
> > I think it's annoying you have to do these calls to determine if there's
> > a valid frontface here for each line instead of just per draw call but
> > it doesn't seem easy to avoid it.
>
> Yea, there'
Looks alright to me.
I just wonder if it would be possible to factor this logic into a separate
function somehow.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Turns out it is actually very complicated to figure out what a format really
> is wrt range, as using channel info
Series looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Going to need this soon (not going to bother with avx2 intrinsics at this
> time
> but don't want to do workarounds for true vector shifts if llvm itself can
> use
> them just fine and won't need the gazil
Series looks good.
You might want to promote XXX to FIXME. Fixing wouldn't be hard -- just need to
pass some additional parameters to this function, so that we can check that
MIN/MAG filter are same.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Detected this hunting some
Great catch!
Jose
- Original Message -
> From: Roland Scheidegger
>
> block size depth is always 1 even for compressed formats (unless someone
> invents true 3d compressed formats at least which we can't represent).
> Nearest (and soa) path had it right.
> ---
> src/gallium/auxiliary/g
- Original Message -
> On 08/26/2013 02:38 AM, Dave Airlie wrote:
> > Hi TGSI guys mostly :-)
> >
> > So I'm wondering how circular and perfect tgsi->text->tgsi roundabouts
> > should be,
>
> Ideally, they should be consistent.
>
>
> > currently the TGSI dump code uses .4f in one place
- Original Message -
> On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie wrote:
> >>> IMM[0] FLT32 { 0x, 0x, 0x, 0x } # 1.0, 3.0, 2.0, 4.0
> >>
> >> If you use "%.9g" instead of "%.4f" then floating point numbers will be
> >> preserved without loss of precision.
> >>
> >
> > I
draw_aaline_prepare_outputs(draw, draw->pipeline.aaline);
> }
>
> /**
> --
> 1.8.1.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
reak them.
>
> Marek
>
> On Wed, Aug 28, 2013 at 3:57 PM, Jose Fonseca wrote:
> > - Original Message -
> >> On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie wrote:
> >> >>> IMM[0] FLT32 { 0x, 0x, 0x, 0x } # 1.0, 3.0, 2.0, 4.0
&g
LGTM.
Jose
- Original Message -
> From: Roland Scheidegger
>
> This is just preparation for per-pixel (or per-quad in case of multiple
> quads)
> min/mag filter since some assumptions about number of miplevels being equal
> to number of lods no longer holds true.
> This change does not
Series looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> The only reason this was needed was because the fetch texel function had to
> get the (dynamic) border color, but this is now done much earlier.
> ---
> src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |
Series LGTM.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Turns out we don't need to do much extra work for detecting this case,
> since we are guaranteed to get a empty static texture state in this case,
> hence just rely on format being 0 and return all zero then.
> Previo
Replying privately.
See also http://bugzilla.eng.vmware.com/show_bug.cgi?id=999655#c5
Jose
- Original Message -
> Hmm sure it is rarely used (for arb_vp and d3d9 vs 1.1 (2.0 too maybe
> though the semantics are different there even if the precision required
> is the same)?
> The proble
GLSL does not use it.
vs_2_0 does not use it either
http://msdn.microsoft.com/en-us/library/windows/desktop/bb173373(v=vs.85).aspx
D3D10 doesn't have similar thing neither.
It just didn't seem worth to keep this special path. And it seemed hard to fix
it without breaking NaN/Inf correctness.
LGTM.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Simply adjust wrap mode to clamp_to_edge. This is all that's needed for a
> correct implementation for nearest filtering, and it's way better than
> using repeat wrap for instance for linear filtering (though obviously this
- Original Message -
> Isn't u_blit a candidate for removal considering it has no user in Mesa?
u_blit still has users outside mesa. And it provides features that
pipe_context::blit does not:
- util_blit_pixels() will call pipe_context::resource_copy for non-stretch
blits, which is pote
- Original Message -
> Am 17.09.2013 20:32, schrieb jfons...@vmware.com:
> > From: José Fonseca
> >
> > By calling util_map_texcoords2d_onto_cubemap.
> >
> > A new parameter for util_blit_pixels_tex is necessary, as
> > pipe_sampler_view::first_layer is always supposed to point to the fi
Sounds good to me. Thanks.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Technically without seamless filtering enabled GL allows any wrap mode, which
> made sense when supporting true borders (can get seamless effect with border
> and CLAMP_TO_BORDER), but gallium doesn't su
- Original Message -
> Am 19.09.2013 20:43, schrieb Zack Rusin:
> > Compress empty triangles (don't emit more than one in a row) and
> > never emit empty triangles if we already generated a triangle
> > covering a non-null area. We can't skip all null-triangles
> > because c_primitives ex
- Original Message -
> Am 24.09.2013 22:26, schrieb Zack Rusin:
> > We need to subdivide triangles if either of the dimensions is
> > larger than the max edge length, not when both of them are larger.
> >
> > Signed-off-by: Zack Rusin
> > ---
> > src/gallium/drivers/llvmpipe/lp_setup.c
case TGSI_OPCODE_BRA:
> - case TGSI_OPCODE_DIV:
> case TGSI_OPCODE_PUSHA:
> case TGSI_OPCODE_POPA:
> case TGSI_OPCODE_SAD:
> --
> 1.7.9.5
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
se.
> + */
> + res = lp_build_negate( &bld_base->int_bld, res );
> + break;
> + case TGSI_TYPE_VOID:
> + default:
> + /* dunno how that should work if legal just ignore? */
> + assert(0);
> + break;
>
I think that we should probably allow signed everywhere.
The operation and result may be unsigned, but the arguments may need to be
negated to become unsigned.
Imagine:
int a = -1;
unsigned b = 10 / (unsigned)-a;
That is
MOV TEMP[0], INT IMM{-1}
UDIV TEMP[1], UINT IMM{10}, -TEMP
; that rare) which should rather be explicit.
>
> Roland
>
>
> Am 15.02.2013 16:32, schrieb Jose Fonseca:
> > I think that we should probably allow signed everywhere.
> >
> > The operation and result may be unsigned, but the arguments may need to be
> > negated t
Both patches look great to me.
Reviewed-by: Jose Fonseca
- Original Message -
> To help catch mixed up context pointer bugs in the future, add a
> trace_context_check() function and some new assertions.
> ---
> src/gallium/drivers/trace/tr_context.c | 15 ++
Thanks for fixing this Roland.
This is definitely an improvement. I'd recommend a few tweaks (it could even be
as a follow on change):
- Calling llvmpipe_flush_resource() in a loop is overkill (it will call
llvmpipe_flush() to be called many times needlessly). Please refactor
llvmpipe_flush_re
There may be more vertex elements that used in the shader. But why should the
key contain those elements? Won't this cause needless recompilations (e.g., in
situations where the state tracker leaves unneeded elements from previous
draw?)?
That is, it seems to be that the key should have the num
- Original Message -
> Am 19.02.2013 15:57, schrieb Jose Fonseca:
> > There may be more vertex elements that used in the shader. But why should
> > the key contain those elements? Won't this cause needless recompilations
> > (e.g., in situations where the sta
igned int
> llvmpipe_is_resource_referenced( struct pipe_context *pipe,
> struct pipe_resource *presource,
> - unsigned level, int layer)
> + unsigned level)
> {
> struct llvmpipe_context *llvmpipe = llvm
Looks good to me.
Jose
- Original Message -
> We sometimes convert GL_QUAD_STRIP prims into GL_TRIANGLE_STRIP, but
> that changes the results of the u_trim_pipe_prim() call. We need to
> pass the original primitive type to the trim function.
>
> Note that OpenGL's GL_x prim type values
Good catch Roland.
Reviewed-by: Jose Fonseca
Jose
- Original Message -
> From: Roland Scheidegger
>
> For constant and temporary register fetches, the bitcasts weren't done
> correctly for the indirect case, leading to crashes due to type mismatches.
> Simply d
Looks perfect. Thanks Roland.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Some parts calculated key size by using shader information, others by using
> the pipe_vertex_element information. Since it is perfectly valid to have more
> vertex_elements set than the vertex shade
ly seamless if a driver supports it
> (PIPE_CAP_SEAMLESS_CUBE_MAP),
> +resulting in filtering taking samples from multiple surfaces near to the
> edge.
>
> - Width and height must be equal
> - If PIPE_CAP_NPOT_TEXTURES is not supported,
> @@ -170,7 +175,6 @@ D3D11: 2D array textures with the
> D3D11_RESOURCE_MISC_TEXTURECUBE flag
>
> - PIPE_CAP_NPOT_TEXTURES is equivalent to D3D_FEATURE_LEVEL_10_0
> - Cube map arrays require D3D_FEATURE_LEVEL_10_1
> -- TODO: are (non)seamless cube maps supported in D3D11? how?
>
> Surfaces
>
> --
> 1.7.9.5
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Series is
Reviewed-by: Jose Fonseca
- Original Message -
> ---
> src/gallium/drivers/llvmpipe/lp_state_setup.c | 15 +--
> src/gallium/drivers/llvmpipe/lp_state_setup.h |4 ++--
> 2 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/s
a ../../auxiliary/libgallium.la
> $(LLVM_LIBS)
> +lp_test_printf_LDADD = $(TEST_LIBS)
> nodist_EXTRA_lp_test_printf_SOURCES = dummy.cpp
>
> --
> 1.7.10.4
>
> _______
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/me
Roland found a better fix. Please ignore.
Jose
- Original Message -
> From: José Fonseca
>
> Weird format, which Mesa state tracker recently started using.
>
> Fixes segfault in
>
> ./bin/texture-packed-formats -auto
>
> because swizzle[foo] was 0xff for padding channel (X). It sti
- Original Message -
> One of the features Valve asked for, that they expected after using other
> drivers, is that they can easily get information about performance traps
> (and other important stuff) from drivers. We wrote INTEL_DEBUG=perf this
> summer as a quick fix, but it's not how
Pushed now.
- Original Message -
> I'd still like to have this applied.
>
> On Tue, Dec 18, 2012 at 3:16 PM, John Kåre Alsaker
> wrote:
> > On Tue, Dec 18, 2012 at 11:20 AM, Jose Fonseca wrote:
> >> Looks fine.
> >>
> >> I'm curio
p_sampler_static_texture_state(struct
> lp_static_texture_state *state,
> state->level_zero_only = !view->u.tex.last_level;
>
> /*
> -* FIXME: Handle the remainder of pipe_sampler_view.
> +* the layer / element / level parameters are all either dynamic
> +
[ "EDGE_FLAG", "LOC_CUSTOM, TYPE_BOOLEAN, 0, extra_flush_current" ],
>[ "FEEDBACK_BUFFER_SIZE", "CONTEXT_INT(Feedback.BufferSize), NO_EXTRA" ],
>[ "FEEDBACK_BUFFER_TYPE", "CONTEXT_ENUM(Feedback.Type), NO_EXTRA" ],
>
- Original Message -
> Jordan Justen writes:
>
> > Motivated by wanting to see if GenTextures was called by an
> > application while debugging another Steam overlay issue.
>
> Making a systematic MESA_DEBUG=api using dispatch tables and code
> generation seems like it would be nice inste
- Original Message -
> What is this good for? Is it for UAVs? (unordered access views)
No, it is just a standard D3D10 feature:
http://msdn.microsoft.com/en-gb/library/windows/desktop/bb204897.aspx
Not sure if there's a particular use case for it (e.g, maybe DirectCompute uses
this exte
Looks good.
I think the u_surface change could go in separately though.
BTW, now that we can render/sampler from buffers,
llvmpipe_is_resource_referenced needs to be updated: buffer may be referenced
if they have BIND_SAMPLER/RENDERTARGET.
Weshould do something like if !BIND_SAMPLER/RENDERTARG
- Original Message -
> On Wed, Feb 27, 2013 at 1:21 AM, Jose Fonseca wrote:
> > - Original Message -
> >> Jordan Justen writes:
> >>
> >> > Motivated by wanting to see if GenTextures was called by an
> >> > application while debu
Good catch. Thanks!
Jose
- Original Message -
> Catched this that morning
>
>
> From e50374e62254e7532c695bebb3e608242638bb73 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Maxence=20Le=20Dor=C3=A9?= < maxence.led...@gmail.com >
> Date: Wed, 27 Feb 2013 10:24:10 +0100
> Subject: [PATCH] tgs
- Original Message -
> On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger
> wrote:
> > Hi,
> >
> > there is some sloppy usage of bind flags in the opengl state tracker
> > (that is, resources get used for things which they didn't have the bind
> > flag set).
> > We'd really like to enforc
- Original Message -
> On 01.03.2013 11:30, Jose Fonseca wrote:
> > - Original Message -
> >> On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger
> >> wrote:
> >>> Hi,
> >>>
> >>> there is some sloppy usage of bind
I expected that when one sets TRACE_LIBGL env var with the path for the true
libGL.so.1, then apitrace wouldn't be picking up symbols the overlay -- it
would be taking symbols only from the true libGL.so, there avoiding infinite
recursion.
Jose
- Original Message -----
> Jose
- Original Message -
>
>
> 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 concrete recommendation
Looks good. Thanks for fine tuning these parameters!
Jose
- Original Message -
> We advertise a max texture/surfaces size of 8K x 8K but the old values
> for these limits didn't actually allow us to handle that surface size.
>
> For 8K x 8K we'll have 16384 bins. Each bin needs at least
> --
> 1.7.3.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
er,
>}
> }
> *p_output = output;
> - shader->emitted_primitives += num_primitives;
> + shader->emitted_primitives += num_primitives;
> }
>
> /*#define DEBUG_INPUTS 1*/
> --
> 1.7.10.4
>
Series looks great Zack
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Patches 1-2 look good to me. Still going through patch 3.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Can handle them since the single sampler interface was introduced.
> ---
> src/gallium/auxiliary/tgsi/tgsi_exec.c | 18 +-
> 1 file changed, 13 insertion
- Original Message -
> From: Roland Scheidegger
>
> This is needed for handling the dx10-style sample opcodes.
> This also simplifies the logic by getting rid of sampler variants
> completely (sampler_views though OTOH have sort of variants because
> some of their state is different depen
- Original Message -
> Am 08.03.2013 21:03, schrieb Jose Fonseca:
> > - Original Message -
> >> From: Roland Scheidegger
> >>
> >> This is needed for handling the dx10-style sample opcodes.
> >> This also simplifies the logic by ge
Looks a sensible thing to do.
Reviewed-by: Jose Fonseca
Any insight how the caller can be fixed so that this doesn't happen?
Jose
- Original Message -
> With the current code, the sampler count can become higher than
> PIPE_MAX_SAMPLERS and once it gets to the driver this
- Original Message -
> On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca wrote:
> > Looks a sensible thing to do.
> >
> > Reviewed-by: Jose Fonseca
> >
>
> Thanks for the review.
>
> > Any insight how the caller can be fixed so that this doesn
First email was too long, so re-sending just the interesting bits)
From: José Fonseca
Unused/unmaintained.
---
configure.ac | 21 -
src/gallium/docs/source/context.rst|2 +-
src/gallium/state_trackers/d3d1x/.gitignore| 20 -
- Original Message -
> On 11.03.2013 11:26, Jose Fonseca wrote:
> > First email was too long, so re-sending just the interesting bits)
>
> Please tell me removing this came to mind because you're going to
> release a better D3D9,10/11 state tracker :)
> (Nah I
Christian,
I didn't comment on the previous threads, but the approach mentioned in
http://lists.freedesktop.org/archives/mesa-dev/2012-November/030476.html seems
sensible to me.
I think after the first round we should have this in a branch to allow drivers
to catch up with the interface change
I'm surprised this is is faster.
In particular, for big things we'll be touching memory twice.
Did you measure the speed up?
Jose
- Original Message -
> ---
> src/mesa/main/readpix.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/readpix.c
- Original Message -
> hot to build mesa
> in
> windows
> use
> mingw scons ?
>
> if use `scons platform=windows toolchain=crossmingw machine=x86 build=release
> mesagdi libgl-gdi`
>
> will happan
>
> [build\windows-x86\mesa\libmesa.a] Error 1
>
> without any tips
Surely there must be
I only skimmed, but looks good in principle.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Previously, the derivatives were calculated and passed in a packed form
> to the sample code (for implicit derivatives, explicit derivatives were
> packed to the same format).
> There's
- Original Message -
> On 03/11/2013 07:56 AM, Jose Fonseca wrote:
> > I'm surprised this is is faster.
> >
> > In particular, for big things we'll be touching memory twice.
> >
> > Did you measure the speed up?
>
> The second hit is cache
- Original Message -
> On 03/11/2013 11:30 AM, Jose Fonseca wrote:
> > - Original Message -
> >> On 03/11/2013 07:56 AM, Jose Fonseca wrote:
> >>> I'm surprised this is is faster.
> >>>
> >>> In particular, for big
- Original Message -
> Am 11.03.2013 15:52, schrieb Jose Fonseca:
> > Christian,
> >
> > I didn't comment on the previous threads, but the approach mentioned in
> > http://lists.freedesktop.org/archives/mesa-dev/2012-November/030476.html
> > seems
- Original Message -
> On 03/12/2013 02:49 PM, Brian Paul wrote:
> > On 03/12/2013 02:39 PM, jfons...@vmware.com wrote:
> >> From: José Fonseca
> >>
> >> ---
> >> common.py | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/common.py b/common.py
> >> index 6ff9
- Original Message -
> On Tue, Mar 12, 2013 at 10:31 AM, Christian König
> wrote:
> > Am 12.03.2013 02:48, schrieb Marek Olšák:
> >
> >> On Mon, Mar 11, 2013 at 1:44 PM, Christian König
> >> wrote:
> >>>
> >>> Hi everybody,
> >>>
> >>> this problem has been open for quite some time now,
Looks good to me.
Jose
- Original Message -
> If geometry shader is present its stream output info should
> be used instead of the vs and we shouldn't use the pre-clipped
> corrdinates.
>
> Signed-off-by: Zack Rusin
> ---
> .../draw/draw_pt_fetch_shade_pipeline_llvm.c |2 +-
>
This patch has some #if near the end. It's not clear if it should be
removed or completed.
Otherwise the series looks good AFAICT.
Jose
- Original Message -
> ---
> src/gallium/state_trackers/osmesa/osmesa.c | 828
>
> 1 files changed, 828 insertions
ck'.
>
> On 03/12/2013 03:07 PM, Jose Fonseca wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 70fe7c6d3e1c7534f6598c4616bebf672f42668b
> > URL:
> > https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D70fe7c6d3
busted with the recent autotools changes.
>
> Jose
>
> - Original Message -
> > I'm pretty sure this commit broke 'make check'.
> >
> > On 03/12/2013 03:07 PM, Jose Fonseca wrote:
> > > Module: Mesa
> > > Branch:
- Original Message -
> On 03/13/2013 01:14 AM, Jose Fonseca wrote:
> > Sorry. I'll look into it. I did try running make locally, but it was not
> > representative because it didn't have everything enabled.
> >
> > BTW, scons is also busted with the rece
- Original Message -
> Second attempt, 2 years ago no one replied or cared ...
>
> We really need to know about these on nvc0 because there are only 8
> fixed hardware locations that can be overwritten by sprite coordinates,
> and one location that represents gl_PointCoord and unconditiona
Series looks good to me.
Reviewed-by: Jose Fonseca
- Original Message -
> From: Roland Scheidegger
>
> Those cases were apparently forgotten.
> ---
> src/gallium/auxiliary/tgsi/tgsi_exec.c | 30 +++---
> 1 file changed, 11 insertion
Looks good. Thanks.
I saw this warning transiently, but then couldn't see it again -- completely
forgot that I needed to rebuild in order to force a recompile.
Jose
- Original Message -
> There were two different NUM_ENTRIES #defines for the framebuffer
> tile cache and the texture tile
Mesa source tree currently has 4 abstraction of threading primitives (in
gallium, glapi, mapi, and egl components).
I'd like to unify all them, and since now the C11 standard introduced a
threads.h header, I'd like to use that as model.
So for I've imported a C11 threads.h implementation from
- Original Message -
> On 03/14/2013 05:10 PM, Jose Fonseca wrote:
> > Mesa source tree currently has 4 abstraction of threading primitives (in
> > gallium, glapi, mapi, and egl components).
> >
> > I'd like to unify all them, and since now the C11 sta
Looks good to me. Please add all necessary test cases to cover all these code
paths.
Good stuff guys. Very subtle code indeed.
Jose
- Original Message -
> From: Roland Scheidegger
>
> If we're in some conditional or loop we must not return, or the code
> after the condition is never
- Original Message -
>
>
> Hi,
>
> I am receiving the following error while compiling the code in the mapi
> directory. I am using mesa 7.5.
If you're compiling with MSVC I'd recommend using a recent Mesa release and
save your self a world of trouble. It's known to build well there.
I
I think this is fine in principle, but I believe it's better to be exhaustive
now than to waste time debugging unsigned/signed stride mismatches later.
Especially all src/gallium/auxiliary/util modules should be updated:
- src/gallium/auxiliary/util/u_format_*
- src/gallium/auxiliary/util/u_surf
- Original Message -
> On Tue, Mar 19, 2013 at 8:29 AM, Dave Airlie wrote:
> >> Errr, what about using flush_frontbuffer, it seems todo
> >> the exact same thing.
> > Hmm I wonder if I could overload it actually I hadn't considered that,
> > its not exactly the same thing,
> > but its pret
- Original Message -
> So we have this virtual GPU with nothing approaching a 3D engine,
> so we are currently running llvmpipe with drisw on it. However
> this incurs some overheads that now that we have a kernel driver,
> I believe we can remove.
>
> The main overheads are putimage for a
LGTM.
Jose
- Original Message -
> Use vmw_printf() just for extra debugging info (off by default).
> Use vmw_error() for real errors/failures/etc that we definitely
> want to report.
> ---
> src/gallium/winsys/svga/drm/vmw_context.h | 10 +++
> src/gallium/winsys/svga/drm/vmw_
> + full_declaration.Array = tgsi_default_declaration_array();
>
> return full_declaration;
> }
> --
> 1.7.3.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
stant included?
> #include MAPI_ABI_HEADER
>
> Thanks,
> Ritvik
>
> -----Original Message-
> From: Jose Fonseca [mailto:jfons...@vmware.com]
> Sent: Monday, March 18, 2013 11:29 PM
> To: Sharma, Ritvik
> Cc: mesa-dev@lists.freedesktop.org
> Subje
t; makefilesand not the makefiles given in the mesa kit. Could this be a reason
> for why I am getting the errors?
>How are the python functions initializing the C constants?
>
> Thanks,
> Ritvik
>
> -Original Message-
> From: Jose Fonseca [mailto:jfons...@vmw
- Original Message -
> From: Roland Scheidegger
>
> New conversion code to handle conversion from/to r11g11b10 AoS to/from
> SoA floats, and also add code for conversion from rgb9e5 AoS to float SoA
> (which works pretty much the same as r11g11b10 except for the packing).
> (This code sho
- Original Message -
> Am 22.03.2013 13:28, schrieb Jose Fonseca:
> >> @@ -1009,6 +1020,17 @@ lp_blend_type_from_format_desc(const struct
> >> util_format_description *format_desc
> >> unsigned i;
> >> unsigned chan;
301 - 400 of 2351 matches
Mail list logo
