- Original Message -
> On Fri, May 2, 2014 at 10:11 AM, wrote:
>
> > From: José Fonseca
> >
> > Just include stdint.h.
> > ---
> > src/egl/main/eglcompiler.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/egl/main/eglcompiler.h b/src/egl/main/eglc
- Original Message -
>
>
> - Original Message -
> > On Fri, May 2, 2014 at 10:11 AM, wrote:
> >
> > > From: José Fonseca
> > >
> > > Just include stdint.h.
> > > ---
> > > src/egl/main/eglcompiler.h | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > di
- Original Message -
> On Fri, May 2, 2014 at 10:11 AM, wrote:
>
> > From: José Fonseca
> >
> > Just include stdint.h.
> > ---
> > src/egl/main/eglcompiler.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/egl/main/eglcompiler.h b/src/egl/main/eglc
Cross-compiling Mesa for windows on linux with mingw is dead easy:
- install mingw-w64 C/C++ cross-compilers (any recent linux distro already
has the packages)
- run
scons platform=windows libgl-gdi
The opengl32.dll drop-in replacement will in
mesa/build/windows-x86-debug/gallium/ta
Series LGTM.
Jose
- Original Message -
> Remove default switch case so we're warned of missing cases at compile
> time.
> ---
> src/gallium/drivers/svga/svga_screen.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/
- Original Message -
> On Fri, May 9, 2014 at 2:55 AM, wrote:
> > From: José Fonseca
> >
> > That information misleads source code auditing tools to think that
> > ralloc itself is released under LGPL v3.
> >
> > Instead, simply state talloc is not licensed under a permissive license.
- Original Message -
> On 05/09/2014 12:48 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> On Fri, May 9, 2014 at 2:55 AM, wrote:
> >>> From: José Fonseca
> >>>
> >>> That information mislea
My recent patch series removes this function altogether.
Jose
- Original Message -
> From: Roland Scheidegger
>
> gallivm_verify_function is the only caller of gallivm_optimize_function
> and it already does this (except it's enabled there).
> ---
> src/gallium/auxiliary/gallivm/lp_bld
gt;inputs[slot].usage_mask;
>for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
> - if (usage_mask & (1 << i)) {
> - float a0 = sa0 [1 + slot][i];
> - float dadx = sdadx[1 + slot][i];
> - float dady = sdady[1 + slot][i];
> -
> - debug_printf("IN[%u].%c: a0 = %f, dadx = %f, dady = %f\n",
> - slot,
> - "xyzw"[i],
> - a0, dadx, dady);
> - }
> + if (usage_mask & (1 << i)) {
> +float a0 = sa0 [1 + slot][i];
> +float dadx = sdadx[1 + slot][i];
> +float dady = sdady[1 + slot][i];
> +
> +debug_printf("IN[%u].%c: a0 = %f, dadx = %f, dady = %f\n",
> + slot, "xyzw"[i], a0, dadx, dady);
> + }
>}
> }
> }
> --
> 1.9.1
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
- Original Message -
> On 05/09/2014 02:55 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > That information misleads source code auditing tools to think that
> > ralloc itself is released under LGPL v3.
> >
> > Instead, simply state talloc is not licensed under a permissive
- Original Message -
> On 05/13/2014 06:01 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > I saw that LLVM internally uses its global context for some things, even
> > when we use our own. Given ours is also global, might as well use
> > LLVM's.
> >
> > However, sepearate
- Original Message -
> Am 13.05.2014 14:01, schrieb jfons...@vmware.com:
> > From: Frank Henigman
> >
> > Split free_gallivm_state() into two steps. First step is
> > gallivm_free_ir() which cleans up the LLVM scaffolding used to generate
> > code while preserving the code itself. Sec
- Original Message -
> Am 13.05.2014 14:01, schrieb jfons...@vmware.com:
> > From: Frank Henigman
> >
> > Provide a JITMemoryManager derivative which puts all generated code into
> > one memory pool instead of creating a new one each time code is generated.
> > This saves significant me
- Original Message -
>
> Hi Jose,
>
> On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote:
> > I tweaked the comment (was below) but indeed did a poor job. I think I'll
> > just put the original back:
> >
> >"We must never free
- Original Message -
> Am 14.05.2014 09:55, schrieb Michel Dänzer:
> > On 14.05.2014 06:45, Marek Olšák wrote:
> >> From: Marek Olšák
> >>
> >> It works just fine.
> >>
> >> This fixes a crash in:
> >>piglit/spec/glsl-1.20/execution/fs-const-array-of-struct-of-array
> >>
> >> Bugzill
yway. However, doing so results in a huge (more than factor of
> 10)
> + * slowdown in llvm compilation times for some (but not all) shaders
> + * (more specifically, the IR optimization spends way more time in
> + * DominatorTree::dominates). At least with llvm ve
- Original Message -
> On 05/14/2014 03:45 AM, Jose Fonseca wrote:
> > - Original Message -
> >>
> >> Hi Jose,
> >>
> >> On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote:
> >>> I tweaked the comment (was below) but inde
- Original Message -
> Module: Mesa
> Branch: master
> Commit: 3e817e7e56806d8adb8f16c35136045c29908944
> URL:
> https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D3e817e7e56806d8adb8f16c35136045c29908944&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9u
r);
> - }
> + LLVMAddInstructionCombiningPass(gallivm->passmgr);
>LLVMAddGVNPass(gallivm->passmgr);
> }
> else {
> --
> 1.9.1
>
Both
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.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Enabled with GALLIVM_DEBUG=perf (which up to now was only used to print
> warnings for unoptimized code).
>
> While some unexpectedly long shader compile times for some shaders were fixed
> with 8a9f5ecdb
Looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> 2ea923cf571235dfe573c35c3f0d90f632bd86d8 had the side effect of IR counting
> now being done after IR optimization instead of before. Some quick analysis
> shows that there's roughly 1.5 times more IR instruction
Hi Mathias,
Sorry for the delay.
- Original Message -
>
> Hi Jose,
>
> I tried to get my local llvm install again to a point where I can see
> backtrace information, but still failed to get valgrind/massif to print
> these nice backtraces. All of the llvm addresses are not resolved so f
- Original Message -
> Module: Mesa
> Branch: master
> Commit: 8b9302f2b4b0536abb91cb73682ec13640fe9eaf
> URL:
> https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D8b9302f2b4b0536abb91cb73682ec13640fe9eaf&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr
- Original Message -
> On Thu, May 22, 2014 at 12:30 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> Module: Mesa
> >> Branch: master
> >> Commit: 8b9302f2b4b0536abb91cb73682ec13640fe9eaf
> >>
I'll assume there is no objection for the series and take the liberty to push.
Pretty minor stuff anyway.
Jose
- Original Message -
> From: José Fonseca
>
> Fixed upstream.
> ---
> src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(
This is a nice cleanup.
You can use
${CMAKE_SOURCE_DIR}/src/xdemos/glinfo_common.c
instead.
Jose
- Original Message -
> I'm not a cmake expert so I'm not sure my changes to CMakeLists.txt are
> ideal. Doing ../somewhere always feels like a hack.
>
> -Brian
>
>
> On 05/22/2014
I'm happy however you guys want to address this, as long as it builds.
The only reason I added $(top_builddir)/src/loader/libloader.la was because the
autotools build was broken for almost a week. I don't care as much for
autotools build breakage as scons build breakage, but I still don't like
- Original Message -
> This is entirely pointless. The DRI driver does not need any symbols
> from libGL, even if it did
I think DRI drivers did at one point depend on getting some glapi symbols from
libGL.so. I don't recall which situations the DRI driver could be loaded
without libG
gt;
> + if (info->render_condition_enable && !softpipe_check_render_cond(sp))
> + return;
> +
> if (info->src.resource->nr_samples > 1 &&
> info->dst.resource->nr_samples <= 1 &&
>
- Original Message -
> On 29/05/14 16:45, Jose Fonseca wrote:
> > I'm happy however you guys want to address this, as long as it builds.
> >
> > The only reason I added $(top_builddir)/src/loader/libloader.la was because
> > the autotools build was br
> /* depth buffer */
> --
> 1.9.1
> _______
> 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
- Original Message -
> On Sun, Jun 1, 2014 at 12:56 PM, wrote:
> > From: José Fonseca
> >
> > Same as b026b6bbfe3f15c8a7296ac107dc3d31f74e401e, but
> > COLOR_ARRAY_SIZE/SECONDARY_COLOR_ARRAY_SIZE.
> >
> > Ideally we wouldn't munge the incoming state, so that we wouldn't need to
> > unm
- Original Message -
>
>
> - Original Message -
> > On Sun, Jun 1, 2014 at 12:56 PM, wrote:
> > > From: José Fonseca
> > >
> > > Same as b026b6bbfe3f15c8a7296ac107dc3d31f74e401e, but
> > > COLOR_ARRAY_SIZE/SECONDARY_COLOR_ARRAY_SIZE.
> > >
> > > Ideally we wouldn't munge the
- Original Message -
> From: José Fonseca
>
> At least on MSVC we statically link against the CRT, so we must disable
> the CRT message boxes if we want to attended testing.
oops: "to attended" -> "unattended"
Jose
>
> The messages are convenient when running manually, so let them be
The second patch didn't make the list. Probably because I'm not the author. Not
sure exactly how to get git send-email to handle that properly. I'll retry
sending it shortly.
Anyway, the change is on
http://cgit.freedesktop.org/~jrfonseca/mesa/commit/?h=gl-rasterization-rules&id=a3910fbee7d95af
- Original Message -
> Do we really need the lower_left_origin state? I think I can't
> implement it for radeon and it's the kind of stuff that should be
> taken care of by the state tracker anyway.
My understanding is that hardware had switches for this sort of thing. It's
really hard t
- Original Message -
> - Original Message -
> > Do we really need the lower_left_origin state? I think I can't
> > implement it for radeon and it's the kind of stuff that should be
> > taken care of by the state tracker anyway.
>
> My understanding is that hardware had switches f
- Original Message -
> On 21.04.2013 09:36, Jose Fonseca wrote:
> > - Original Message -
> >> Do we really need the lower_left_origin state? I think I can't
> >> implement it for radeon and it's the kind of stuff that should be
> >
vior.
Maybe I'm not explaining myself properly -- one can keep the current behavior
merely by ignoring the lower_left_origin bit -- so I really don't see any need
for concern.
> Marek
>
Jose
> On Sun, Apr 21, 2013 at 9:36 AM, Jose Fonseca wrote:
> > - Orig
- Original Message -
> On 21.04.2013 12:34, Dave Airlie wrote:
> > On Sun, Apr 21, 2013 at 5:36 PM, Jose Fonseca wrote:
> >> - Original Message -
> >>> Do we really need the lower_left_origin state? I think I can't
> >>> implemen
- Original Message -
> On 21.04.2013 13:18, Jose Fonseca wrote:
> >
> > - Original Message -
> >> On 21.04.2013 09:36, Jose Fonseca wrote:
> >>> - Original Message -
> >>>> Do we really need the lower_left_origin state?
or
exclusive. I'm open for better name suggestions.
Jose
> On Sun, Apr 21, 2013 at 2:35 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> On 21.04.2013 13:18, Jose Fonseca wrote:
> >> >
> >> > - Original Mes
- Original Message -
> - Original Message -
> > I have managed to make the triangle-rasterization test pass. Let's
> > forget about what the origin is, because it's not really important.
> > What is actually important is what happens when an edge falls exactly
> > on a sample poin
- Original Message -
> Some suggestions for the name:
>
> lower_left_edge_rule
> lower_left_rasterization_edge_rule
> gl_edge_rule
> gl_rasterization_edge_rule
>
> In this case, the name is not as important as the documentation which
> defines the behavior of the state.
On that note, I t
- Original Message -
> From: Christopher James Halse Rogers
>
> This is only exposed by drivers wich support the new PIPE_CAP_PRIME
> parameter,
> for PRIME import/export.
What does exactly PIPE_CAP_PRIME entail? Please document it.
Jose
___
m
SPATCH(ObjectPurgeableAPPLE);
> COPY_DISPATCH(ObjectUnpurgeableAPPLE);
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
count);
> + u_decomposed_prims_for_vertices(prim_info->prim, prim_info->count);
> draw->statistics.vs_invocations += fetch_info->count;
> }
>
> --
> 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
if (state->shader.tokens == NULL)
> + goto fail;
>
> - state->max_sampler = state->draw_data->info.file_max[TGSI_FILE_SAMPLER];
> + state->draw_data = draw_create_geometry_shader(softpipe->draw, templ);
> + if (state->draw_data == NULL)
>
Looks good to me.
Jose
- Original Message -
> From: Tom Stellard
>
> ---
>
> src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 4
> src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_deb
thank you for fixing this. I would have probably never knew
> how to fix the triangle rasterization tests if you didn't bring this
> up.
>
> Marek
>
> On Sun, Apr 21, 2013 at 7:54 PM, Jose Fonseca wrote:
> > - Original Message -
> >
debug_assert(input_prims->primitive_count == 1);\
>switch (prim) { \
> --
> 1.7.10.4
>
LGTM
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > how to fix the triangle rasterization tests if you didn't bring this
> > up.
> >
> > Marek
> >
> > On Sun, Apr 21, 2013 at 7:54 PM, Jose Fonseca wrote:
> > > - Original Message -
> > >> Some suggestions for the name:
> > >&g
ge.
Jose
> Marek
>
> On Tue, Apr 23, 2013 at 6:39 PM, Jose Fonseca wrote:
> > My follow on changes can be seen at
> > http://cgit.freedesktop.org/~jrfonseca/mesa/log/?h=gl-rasterization-rules
> >
> > Jose
> >
> > - Original Message --
- Original Message -
> On Wed, Apr 24, 2013 at 10:23:38AM +0100, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > Running piglit with was causing all sort of weird stuff happening to my
> > desktop (Chromium webpages become blank, Qt Creator flickered, etc). I
> > tracked this d
- Original Message -
> On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote:
> >
> > Hi Tom,
> >
> > On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote:
> > > First of all, thanks for investigating this. The information you've
> > > provided has helped me a lot.
> > Good
- Original Message -
>
> Hi,
>
> On Wednesday, April 24, 2013 21:54:02 Jose Fonseca wrote:
> > I don't see how this would work -- llvmpipe/draw has LLVMBuildXxxx calls
> > too. So to prevent symbol collision with apps that use them, we'd need to
>
- Original Message -
>
> Jose,
>
> On Thursday, April 25, 2013 01:38:46 Jose Fonseca wrote:
> > What I'm suggesting doesn't require huge effort.
> >
> > In detail, I'm suggesting:
> >
> > (1) have a custom build of LLVM l
- Original Message -
> On Wed, Apr 24, 2013 at 09:54:02PM -0700, Jose Fonseca wrote:
> > - Original Message -
> > > On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote:
> > > >
> > > > Hi Tom,
> > > >
> >
Looks good to me. Thanks.
Jose
- Original Message -
> If the size is 0, there is nothing to do and st_obj->buffer can be NULL.
> st_obj->buffer should not be NULL in any other case.
>
> This fixes a segfault in Topogun. Reported by Jose Fonseca.
> ---
>
- Original Message -
> Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
> uses anonymous unions which this disables.
>
> It doesn't look too difficult to fix, just wondering if there was a
> reason for using anon unions in the first place?
FWIW, anonymous unions are
- Original Message -
> On Fri, Apr 26, 2013 at 4:48 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
> >> uses anonymous unions which this disables.
> &g
Seems fine to me. Though you might also want to update
src/gallium/auxiliary/rtasm/rtasm_execmem.c while you're at it.
Jose
- Original Message -
> * Haiku recently got DEP support which can result in the
> OS locking down execution in non-exec flagged memory.
> ---
> src/mesa/main/exe
Looks good to me.
Jose
- Original Message -
> Signed-off-by: Adam Jackson
> ---
> src/gallium/auxiliary/gallivm/lp_bld_arit.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> b/src/gallium/auxiliary/gallivm/lp_bl
+ if (lp->so_targets[i]) {
> + buf = llvmpipe_resource(lp->so_targets[i]->target.buffer)->data;
> + lp->so_targets[i]->mapping = buf;
> + }
> }
> draw_set_mapped_so_targets(draw, lp->num_so_targets,
>lp-&g
- Original Message -
>
> Hi,
>
> On Thursday, April 25, 2013 10:29:27 Jose Fonseca wrote:
> > - There are a bunch of options that need to be set via globals, (see
> > lp_set_target_options), so app/drivers could tamper with each other
> &g
- Original Message -
> I seem to recall adding a bunch of null pointer checks to the
> st_cb_bufferobjects.c code in the past to avoid crashing in some
> out-of-memory situations. I think we should check for null pointers
> wherever possible.
FWIW, the fix that I suggested privately to Ma
- Original Message -
> From: Dave Airlie
>
> Not sure if this makes a difference or not, but either its inconsistent
> for some undocumented reason or its just a bug.
PIPE_TRANSFER_UNSYNCHRONIZED only makes sense when one maps for the 2nd time
(or after). It really makes no sense to s
>count == 0) {
> + debug_printf("GS/IA didn't emit any vertices!\n");
> +
> + FREE(vert_info->verts);
> + if (free_prim_info) {
> + FREE(prim_info->primitive_lengths);
> + }
> + return;
> + }
>
> /* stream
- Original Message -
> On 04/27/2013 06:57 AM, Zack Rusin wrote:
> > Technically it's legal for geometry shader to not emit any
> > vertices. It's silly, but perfectly legal, so lets make draw
> > stop crashing if it happens.
> >
> > Signed-off-by: Zack Rusin
> > ---
> > src/gallium/aux
- Original Message -
> On Mon, Apr 29, 2013 at 2:52 PM, Dave Airlie wrote:
> > I've been playing with a gallium driver, and started looking at some
> > wierd gears behaviour,
> >
> > The vbo code maps the buffer with GL_MAP_FLUSH_EXPLICIT_BIT which to
> > me requires that at some point
> >
- Original Message -
> MSVC doesn't like pointer arithmetic with void * so use GLubyte *.
> ---
> src/mesa/swrast/s_texfetch_tmp.h |8
> src/mesa/swrast/s_texfilter.c|2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/swrast/s_texfetch_
- Original Message -
> > > What is "IA"?
> >
> > "Input Assembly", a D3D10 term that roughly matches pipe_vertex_elements /
> > pipe_vertex_buffer state.
> >
> > BTW, I think that Chris Forbes makes a good point -- a GS might choose to
> > not emit any vertices (e.g., that does fancy c
- Original Message -
> - Original Message -
> > Am 02.05.2013 03:13, schrieb Zack Rusin:
> > > It's valid. Some shaders do the negation on unsigned and then
> > > use the results in opcodes taking signed integers.
> > >
> > > Signed-off-by: Zack Rusin
> > > ---
> > > src/galliu
lot][0][prim_idx],
> - (*input_data)[i][slot][1][prim_idx],
> - (*input_data)[i][slot][2][prim_idx],
> - (*input_data)[i][slot][3][prim_idx]);
> + debug_printf("\t\t%f %f %f %f\n",
> +(*input_data)[i][slot][0][prim_idx],
> +(*input_data)[i][slot][1][prim_idx],
> +(*input_data)[i][slot][2][prim_idx],
> +(*input_data)[i][slot][3][prim_idx]);
> #endif
> -++vs_slot;
> + ++vs_slot;
> +}
> }
>}
> }
> --
> 1.7.10.4
>
Series is
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
- Original Message -
> Currently, there's no way to get the high bits of a 32x32
> signed/unsigned integer multiplication with tgsi.
> However, all of d3d10, OpenGL, and OpenCL support that, so we need it as
> well.
> There's essentially two ways how it could be done:
> - a 2-destination
- Original Message -
> It should be unsigned, not enum pipe_flush_flags.
>
> Fixed a build error:
>
> src/gallium/state_trackers/egl/android/native_android.cpp:426:29: error:
> invalid conversion from 'int' to 'pipe_flush_flags' [-fpermissive]
>
While I agree that using enum for bit
- Original Message -
> In ureg src registers could have an indirect register that was
> either a temp or an addr register, while dst registers allowed
> only addr. That made moving between them a little difficult so
> make them behave the same way and allow temp's and addr registers
> as in
- Original Message -
> From: Roland Scheidegger
>
> A lot of them were missing. Others were moved from the Compute ISA
> to a new Integer ISA section as that seemed more appropriate.
> ---
> src/gallium/docs/source/tgsi.rst | 362
> ++
> 1 file cha
- Original Message -
> > Sorry to hear the hw doesn't support it, but this is supported by d3d10
> > so it's quite likely some hw indeed supports it. There's always some
> > things some hw can't do natively.
>
> Well I was hoping before adding new things for sw driver to gallium we
> shoul
- Original Message -
> On Thu, May 2, 2013 at 11:40 PM, Zack Rusin wrote:
> > gallium lies. buffer_size is not actually buffer_size but available
> > size, which is 'buffer_size - buffer_offset' so by adding buffer
> > offset we'd incorrectly compute overflow.
>
> Maybe add a comment to
Fine by me.
Jose
- Original Message -
> One build system for linux/unix only drivers should be enough.
> Additionally the nouveau target was disabled anyway.
> ---
> src/gallium/SConscript | 15 ---
> src/gallium/drivers/nouveau/SConscript | 10 --
Looks ok by me.
- Original Message -
> From: Tom Stellard
>
> This does not solve all of the problems with using LLVM in a
> multithreaded enivronment, but it should help in some cases.
> ---
> src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 15 +++
> src/gallium/drivers/r
- Original Message -
> Am 03.05.2013 06:58, schrieb Jose Fonseca:
> >
> >
> > - Original Message -
> >> Currently, there's no way to get the high bits of a 32x32
> >> signed/unsigned integer multiplication with tgsi. However, all of
Series looks alright AFAICT.
Jose
- Original Message -
> A surprising number of apps and benchmarks have poor code like this:
>
> glBegin(GL_LINE_STRIP);
> glVertex(v1);
> glVertex(v2);
> glEnd();
> // Possibly some no-op state changes here
> glBegin(GL_LINE_STRIP);
> glVertex(v3);
> glVe
Looks good AFAICT
- Original Message -
> From: Roland Scheidegger
>
> Adds the remaining integer opcodes, and some opcodes are moved to more
> appropriate places, along with getting rid of the (already nearly empty)
> ps_2_x section. Though the CAP bits for some of these are still a bit
- Original Message -
> The SUB opcode is not emitted by GLSL, however this may change in the
> future. I don't think using specialized opcodes instead of the
> modifiers will make anyone's life easier (the modifiers must be
> implemented anyway).
>
> If you really want people to follow the
I don't really care much about modifiers vs no-modifiers, or ABS/SUB opcodes vs
no opcodes. It is merely a convention, and as long as we consistently follow
it we're good IMO.
I am, however, worried about this growing trend of long threads about TGSI with
little more than nitpicking. I think
Series looks good to me.
Jose
- Original Message -
> The support is analogous to the way we handle indirect addressing
> in temporaries, except that we don't have to worry about storing
> (after declarations) and thus we'll able to keep using the old
> code when indirect addressing isn't
I somehow thought that GL_ARB_robustness that had something for this, but
apparently it was just my imagination.
Anyway, if we particularly cared for robustness of user pointers, we could
query the OS for the virtual address range that contains a pointer. Windows/Mac
have nice APIs for that. Li
- Original Message -
> Le dimanche 12 mai 2013 20:37:17 Vinson Lee a écrit :
> > Signed-off-by: Vinson Lee
> > ---
> > src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_d
This looks a good way to address the problem. Thanks.
I didn't know you were already looking at this and I was in a rush to fix the
regression, I went ahead and pushed a temporary workaround. You'll need to
rebase or revert my workaround -- eitherway it will be trivial.
Jose
- Original M
Looks good to me. Thanks for the quick turnaround.
Jose
- Original Message -
> The indices are not consecutive when using the geometry shader,
> which means we were extracting non existing values. Create
> an array of linear indices and always use it instead of the passed
> indices. Found
- Original Message -
> Am 16.05.2013 21:44, schrieb Adam Jackson:
> > These were mostly just a waste of memory and cache pressure, and were
> > really only used for debugging.
> >
> > This change reduces instruction count (as measured by callgrind's Ir
> > event) of gnome-shell-perf-tool
Vinson,
Why is this necessary?
(I'd prefer that LLVM is statically linked by default. )
Jose
- Original Message -
> This patch fixes SCons builds on Fedora 18.
>
> Signed-off-by: Vinson Lee
> ---
> scons/llvm.py | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> d
_mesa_get_attachment_teximage has no side effects so looks good to me.
Jose
- Original Message -
> All uses of 'texImage' were removed in commit
> 77a405dba7f70f8a47655e90774a5ecf5c88a6ed.
>
> Fixes "Unused pointer value" defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
> --
- Original Message -
> From: Richard Sandiford
>
> RGBA has R at byte 0 and A at byte 3, regardless of platform
> endianness.
Maybe I'm missing something, but this naming convention seems to me the exact
opposite of what was decided [1], which is:
- R at byte 0, ..., and A at byte
Thanks for doing this Roland.
- Original Message -
> From: Roland Scheidegger
>
> We do rendering to linear color buffers for quite some time, and since
> switching to linear depth buffers all the tiled/linear logic was unused.
> So get rid of (most) of it - there's still some LAYOUT_NON
- Original Message -
> On Fri, May 17, 2013 at 7:44 AM, Jose Fonseca wrote:
> > Vinson,
> >
> > Why is this necessary?
> >
> > (I'd prefer that LLVM is statically linked by default. )
> >
> > Jose
>
> The SCons build fails on
ist
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
For series
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Sounds definitely an improvement.
Long term I think the cache is probably not worth to keep any texture cache at
all.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Initially we had NUM_TEX_TILE_ENTRIES of 50, however this was using too much
> memory (mostly because the tile
501 - 600 of 2351 matches
Mail list logo
