- Original Message -
> Hi Jose,
>
> Thanks for the review.
>
> Jose Fonseca writes:
> > - Original Message -
> >> From: Richard Sandiford
> >>
> >> RGBA has R at byte 0 and A at byte 3, regardless of platform
> >>
- Original Message -
> On Die, 2013-05-21 at 23:15 -0700, Jose Fonseca wrote:
> >
> > - Original Message -----
> > > Jose Fonseca writes:
> > > > - Original Message -
> > > >> From: Richard Sandiford
> > > >&
Roland,
Series looks good AFAICT. Thanks for nailing this nasty and long standing
issues.
- Original Message -
> On Tue, May 21, 2013 at 6:12 PM, wrote:
> > From: Roland Scheidegger
> >
> > This optimization disabled mask checks if the shader is simple enough.
> > While this should wo
Context );
> + XMesaGarbageCollect(dpy);
> + free(glxCtx);
> + }
> }
>
>
> --
> 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
- Original Message -
> Michel Dänzer writes:
> >> > For packed formats such as RGBA, the order used in these patches
> >> > (which is what I suggested in my proposal) matches the order humans use
> >> > for digits of numbers, as well as the Mesa formats. That seems more
> >> > import
- Original Message -
> > There's no documentation of PIPE_CAP_MAX_VIEWPORTS but otherwise the
> > series looks good.
>
> I've just sent another patch with it. Let me know if that's enough.
The updated series looks good to me too. Thanks for changes.
Jose
___
n bytes.
> +* ``PIPE_CAP_MAX_VIEWPORTS``: The maximum number of viewports (and scissors
> + since they are linked) a driver can support. Returning 0 is equivalent
> + to returning 1 because every driver has to support at least a single
> + viewport/scissor combination.
>
>
Looks alright AFAICT.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Eliminate the rest of the no longer needed layout logic.
> (It is possible some code could be simplified a bit further still.)
> ---
> src/gallium/drivers/llvmpipe/lp_scene.c |6 +-
> src/gallium
ensions.EXT_texture_compression_s3tc ? GL_RGBA : -1;
>case GL_SLUMINANCE_ALPHA_EXT:
>case GL_SLUMINANCE8_ALPHA8_EXT:
>case GL_COMPRESSED_SLUMINANCE_ALPHA_EXT:
> --
> 1.7.10.4
>
> ___
> mesa-dev mail
Yeah, that looks even better than my fix.
Jose
- Original Message -
> Before, on the second call to GenerateMipmap were enabling two
> vertex arrays for the current vertex array object, rather than
> the private generate-mipmap vertex array object. This caused
> things to blow up elsewhe
Looks great to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Surprising this bug survived so long, we were missing a clamp (in the
> linear filtering version).
> (Valgrind complained a lot about invalid reads with piglit texwrap,
> I've also seen spurios failures in this
- Original Message -
> On Fri, May 31, 2013 at 10:18 AM, José Fonseca
> wrote:
> > I'd support such change. Be it through GL_GREMEDY_string_marker, or
> > ARB_debug_output's glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB,
> > ...), or KHR_debug's glPushDebugGroup(). A Gallium interfa
- Original Message -
> On Mon, Jun 3, 2013 at 10:41 AM, Jose Fonseca wrote:
> > - Original Message -
> >> On Fri, May 31, 2013 at 10:18 AM, José Fonseca
> >> wrote:
> >> > I'd support such change. Be it through GL_GREMEDY
- Original Message -
> Michel Dänzer writes:
> > On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
> >>
> >> I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
> >> them with endian-variant BGR565 and RGB565 makes a lot of sen
- Original Message -
> - Original Message -
> > Michel Dänzer writes:
> > > On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
> > >>
> > >> I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
> > >>
- Original Message -
> On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
> > - Original Message -
> > > Michel Dänzer writes:
> > > > On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
> > > >>
> > > >>
- Original Message -
> Jose Fonseca writes:
> >> Yeah, that's what the patch was trying to do. Even though the formats
> >> were defined as "int"s, the int layout was extra information on top of
> >> what's already there. The int i
- Original Message -
> From: Roland Scheidegger
>
> The code was designed to handle no-op concat but failed (unless the
> caller was using same pointer for src and dst).
> ---
> src/gallium/auxiliary/gallivm/lp_bld_pack.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
pc->MaxParameters = pc->MaxNativeParameters =
> screen->get_shader_param(screen, sh, PIPE_SHADER_CAP_MAX_CONSTS);
>
> --
> 1.7.10.4
>
> _______
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/
- Original Message -
> Without this, llvmpipe ends up giving a zero size to all uncompressed
> textures
> on non-x86 systems, since align() cannot handle a 0 alignment. Making the
> default 1 seemed preferable to adding checks for 0.
>
> Signed-off-by: Richard Sandiford
> ---
> src/ga
- Original Message -
> Am 06.06.2013 03:15, schrieb Brian Paul:
> > Reviewed-by: Brian Paul
> >
> > Just two minor nits below.
> >
> >
> > On 06/05/2013 05:44 PM, srol...@vmware.com wrote:
> >> From: Roland Scheidegger
> >>
> >> Mostly just make sure the layer parameter gets passed t
+80,7 @@ const char *tgsi_semantic_names[TGSI_SEMANTIC_COUNT] =
> "TEXCOORD",
> "PCOORD",
> "VIEWPORT_INDEX"
> + "LAYER"
> };
>
> const char *tgsi_texture_names[TGSI_TEXTURE_COUNT] =
> --
> 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
_TEXTURE_3D_LEVELS 12 /* 2K x 2K x 2K for now */
> +#define LP_MAX_TEXTURE_CUBE_LEVELS 14 /* 8K x 8K for now */
> #define LP_MAX_TEXTURE_ARRAY_LAYERS 512 /* 8K x 512 / 8K x 8K x 512 */
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing lis
- Original Message -
> Am 07.06.2013 12:14, schrieb Marek Olšák:
> >> diff --git a/src/gallium/auxiliary/util/u_transfer.c
> >> b/src/gallium/auxiliary/util/u_transfer.c
> >> index 56e059b..7804f2a 100644
> >> --- a/src/gallium/auxiliary/util/u_transfer.c
> >> +++ b/src/gallium/auxiliary/ut
Looks good to me.
Jose
- Original Message -
> lp_build_add and lp_build_sub have fallback code for cases
> that cannot be handled by known intrinsics. For UNORM formats,
> this code was using modulo rather than saturating arithmetic.
>
> This fixes some rendering issues for a gnome sess
- Original Message -
> Am 07.06.2013 16:55, schrieb Jose Fonseca:
> >
> >
> > - Original Message -
> >> Am 06.06.2013 03:15, schrieb Brian Paul:
> >>> Reviewed-by: Brian Paul
> >>>
> >>> Just two minor nits b
here */
> +
>
>
> /* MESA_FORMAT_YCBCR
> */
> --
> 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
- Original Message -
> Am 11.06.2013 05:39, schrieb Zack Rusin:
> > There are strict limits on those registers. Define the maximums
> > and use them instead of magic numbers. Also allows us to add
> > some extra sanity checks.
> > Suggested by Brian.
> >
> > Signed-off-by: Zack Rusin
>
- Original Message -
[...]
> On an unrelated note ... packing clip distances into vec4s sucks, I want
> scalar arrays.
OMG, then we must fix it!
Now seriously, we had the discussion about packed vs unpacked clip distances --
I don't feel strongly either way and I don't recall the ration
Sounds good. Thanks for tracking this down!
Jose
- Original Message -
> gl can use elts without setting indices, in which case
> our eltMax was set to 0 and always invoking the overflow
> condition. So by default set eltMax to maximum, it will
> be curbed by draw_set_indexes (if it ever c
Sounds good to me.
Jose
- Original Message -
> Since draw auto fetches the count from the buffers, we can't
> just clear them on bind, we need to wait until the actual
> stream out is performed. Otherwise the count for draw auto
> will be zero. Plus is cleaner to have draw do it rather
>
- Original Message -
> - Original Message -
> > Jose Fonseca writes:
> > >> Yeah, that's what the patch was trying to do. Even though the formats
> > >> were defined as "int"s, the int layout was extra information on top of
&
Looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> For conditional rendering this makes it possible to skip rendering
> if either the predicate is true or false, as supported by d3d10
> (in fact previously it was sort of implied skip rendering if predicate
> is f
- Original Message -
> On Sun, 2013-06-16 at 10:22 -0700, Jose Fonseca wrote:
>
> > Ok. I think this patch series is sound from an implementation POV. I
> > see no point in delaying further. We can tweak things afterwards if
> > deemed necessary.
> >
>
- Original Message -
> From: Roland Scheidegger
>
> The semantics didn't really make sense, not really matching neither d3d9
> (though the docs are all broken there) nor d3d10. So make it match d3d10
> semantics, which actually gives meaning to the "disjoint" part.
> Drivers are fixed u
Looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> The driver can do render_condition but wasn't handling the occlusion
> and so_overflow predicates (though the latter might not work yet due
> to gs support).
> ---
> src/gallium/drivers/softpipe/sp_query.c | 3
- Original Message -
>
>
> - Original Message -
> > From: Roland Scheidegger
> >
> > The semantics didn't really make sense, not really matching neither d3d9
> > (though the docs are all broken there) nor d3d10. So make it match d3d10
> > semantics, which actually gives meanin
- Original Message -
> Jose Fonseca writes:
> > - Original Message -
> >> On Sun, 2013-06-16 at 10:22 -0700, Jose Fonseca wrote:
> >>
> >> > Ok. I think this patch series is sound from an implementation POV. I
> >> > se
- Original Message -
> This series is a replacement for the util part of:
>
> http://lists.freedesktop.org/archives/mesa-dev/2013-May/039419.html
>
> It doesn't include any of the controversial format name parts of
> those patches (although of course they're still needed in some form
Series looks good to me too.
Jose
- Original Message -
> Signed-off-by: Adam Jackson
> ---
> src/gallium/docs/format.rst | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/docs/format.rst b/src/gallium/docs/format.rst
> index 2514656..e270d93 1
Yes, that's definetely wrong with the newer query types.
And I agree that for most query types, the situation of nothing being drawned
inside the query is too rare to be of concern.
Though I wonder if we should do better in a follow on patch for time queries --
which applications might emit ind
- Original Message -
> ---
> src/gallium/auxiliary/util/u_format.c | 14 ++
> src/gallium/auxiliary/util/u_format.h | 3 +++
> src/mesa/state_tracker/st_cb_drawpixels.c | 6 ++
> 3 files changed, 23 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_fo
- Original Message -
> On Mon, Jun 24, 2013 at 6:12 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> ---
> >> src/gallium/auxiliary/util/u_format.c | 14 ++
> >> src/gallium/auxiliary/util/u_fo
n change.
Jose
- Original Message -
> Wouldn't it be easier to just make util_format_description table-based
> and inline instead of switch-based? Something like:
>
> return format < PIPE_FORMAT_COUNT ? table[format] : NULL;
>
> Marek
>
> On Mon
Series looks good to me.
- Original Message -
> Because our code couldn't handle it we were skipping rendering
> if we detected overflows. According to the spec we should
> still render but with all 0 vertices, which is what the llvm
> code already does. So for the llvm paths lets enable p
- Original Message -
> We weren't taking into account the size of element
> that is to be fetched, which meant that it was possible
> to overflow the buffer reads if the stride was very
> close to the end of the buffer, e.g. stride = 3, buffer
> size = 4, and the element to be read = 4. T
- Original Message -
> In glapi_priv.h we always need the typedef for the GLclampx type
> since GL_OES_fixed_point is now defined in glext.h but the
> GLclampx type is not. GLclampx is not used by anything in glext.h
> but we need it for GL ES dispatch.
> ---
> include/GL/glext.h
Looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> trivial, copied from llvmpipe
> ---
> src/gallium/drivers/softpipe/sp_surface.c | 42
> +++--
> 1 file changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/s
Series looks good to me.
Jose
- Original Message -
> The 20130624 version of glext.h changed this to match the
> glMultiDrawElements() function which already had the extra const
> qualifier.
>
> Fixes warnings/errors that seem to vary from one compiler to the next.
> ---
> src/mapi/glap
Several components are never expected to be built with MSVC (glx, most dri
drivers), so this would put (most likely undesired) burden on those maintainers.
I suspect we'll need to do this on a per directory basis...
Jose
- Original Message -
> Since it's an error with MSVC.
> ---
> con
The other patches look fine though.
Jose
- Original Message -
> Several components are never expected to be built with MSVC (glx, most dri
> drivers), so this would put (most likely undesired) burden on those
> maintainers.
>
> I suspect we'll need to do this on a per directory basis...
- Original Message -
> On 06/26/2013 04:33 PM, Eric Anholt wrote:
> > Brian Paul writes:
> >
> >> On 06/26/2013 03:56 PM, Ian Romanick wrote:
> >>> Patches 1 and 4 are
> >>>
> >>> Reviewed-by: Ian Romanick
> >>>
> >>> For patch 3, I share Jose's concern. I would very much like to see t
- Original Message -
> From: Roland Scheidegger
>
> This was just ignored (unless for some reason like unfilled polys draw was
> handling this).
Patch looks good.
> I'm not convinced of that code, putting the float for the clamp in the key
> isn't really a good idea.
Indeed.
> Then a
- Original Message -
> From: Roland Scheidegger
>
> If there are queries active the opaque optimization reseting the bin needs to
> be disabled.
> (Not really tested since the bug was discovered by code inspection not
> an actual test failure.)
> ---
> src/gallium/drivers/llvmpipe/lp_que
- Original Message -
> ---
> src/gallium/auxiliary/Makefile.sources |1 +
> src/gallium/auxiliary/os/os_process.c | 86
>
> src/gallium/auxiliary/os/os_process.h | 40 +++
> 3 files changed, 127 insertions(+)
> create mode 100644 s
Series looks great.
Thanks.
Jose
- Original Message -
> We'll be reusing this code so lets put it in a common file
> and use it in the draw module.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/Makefile.sources |1 +
> src/gallium/auxiliary/draw/draw_llvm
- Original Message -
> Safer in case the PIPE_SHADER_x tokens get renumbered (as Marek
> wanted to do).
Renumbering PIPE_SHADER_x seems a pure time waster -- there is much more code
that expects the current order -- and I see no benefit.
This patch looks good nevertheles.
> ---
> src
Looks good to me
- Original Message -
> ---
> src/gallium/drivers/svga/svga_tgsi.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/svga_tgsi.c
> b/src/gallium/drivers/svga/svga_tgsi.c
> index 56529c6..29fbe84 100644
> --
- Original Message -
> See my explanation in mtypes.h.
> ---
> src/gallium/include/pipe/p_defines.h |7 ---
> src/glsl/linker.cpp| 16
> src/mesa/drivers/dri/i965/brw_shader.cpp |8 ++--
> src/mesa/main/mtypes.h
Looks good.
- Original Message -
> From: Roland Scheidegger
>
> b04a295a4a0cd2defe352b3193b5fa79ca8fc9fc removed seemingly unnecessary
> code in get_query. Turns out this code could in fact be reached - while
> timestamps are always binned, if there are no bins (which happens if fb
> siz
- Original Message -
> Brian Paul writes:
>
> > On 06/26/2013 04:33 PM, Eric Anholt wrote:
> >> Brian Paul writes:
> >>
> >>> On 06/26/2013 03:56 PM, Ian Romanick wrote:
> Patches 1 and 4 are
>
> Reviewed-by: Ian Romanick
>
> For patch 3, I share Jose's concer
- Original Message -
> See my explanation in mtypes.h.
>
> v2: don't do this in gallium
Thanks for the update, Marek.
I think that the "These MUST have the same values as gallium's PIPE_SHADER_*"
comment in gl_shader_type enum can be removed now.
Otherwise looks good AFAICT (but note
art, unsigned count)
>
>BEGIN_NIC0(ctx->push, NVC0_3D(VERTEX_DATA), size);
>
> - ctx->translate->run_elts16(ctx->translate, elts, nr, ctx->instance_id,
> + ctx->translate->run_elts16(ctx->translate, elts, nr, 0,
> ctx->in
I don't fully grasp every detail (many paths), but looks good in principle.
Where do the 16xf32 vectors come from?
Also, please add a comment somewhere summarizing all the code paths for lod
handling:
- AVX vs non AVX
- SOA vs AOS
- scalar lod vs stamp lod
But I couldn't spot anything wrong
Series looks good AFAICT.
Reviewed-by: Jose Fonseca
- Original Message -
> The semantics for overflow detection are a bit tricky with
> indexed rendering. If the base index in the elements array
> overflows, then the index of the first element should be used,
> if the ind
Frank,
Sorry for the long delay. Lately I haven't been able to keep up with email,
both internal or external.
This series looks great.
Two comments:
- currently we prefer the old JIT to MCJIT. could you confirm that this series
should work with the old JIT and MCJIT just as well?
- we shou
- Original Message -
> From: Roland Scheidegger
>
> srgb-to-linear is using 3rd degree polynomial for now which should be _just_
> good enough. Reverse is using some rational polynomials and is quite
> accurate,
> though not hooked into llvmpipe's blend code yet and hence unused (untest
- Original Message -
> Am 11.07.2013 15:50, schrieb Jose Fonseca:
> >
> >
> > - Original Message -
> >> From: Roland Scheidegger
> >>
> >> srgb-to-linear is using 3rd degree polynomial for now which should be
> >>
Looks good. Thanks for the updates.
Jose
- Original Message -
> From: Roland Scheidegger
>
> We had to disable fast rsqrt before because it wasn't precise enough etc.
> However in situations when we know we're not going to need more precision
> we can still use a fast rsqrt (which can b
- Original Message -
> From: Roland Scheidegger
>
> srgb-to-linear is using 3rd degree polynomial for now which should be _just_
> good enough. Reverse is using some rational polynomials and is quite
> accurate,
> though not hooked into llvmpipe's blend code yet and hence unused (untested
- Original Message -
> Am 11.07.2013 18:54, schrieb Jose Fonseca:
> > - Original Message -
> >> From: Roland Scheidegger
> >>
> >> srgb-to-linear is using 3rd degree polynomial for now which should be
> >> _just_
> >> good
Looks good. Thanks for the update.
Jose
- Original Message -
> From: Roland Scheidegger
>
> srgb-to-linear is using 3rd degree polynomial for now which should be _just_
> good enough. Reverse is using some rational polynomials and is quite
> accurate,
> though not hooked into llvmpipe's
ite lean and straightforward
these days, but the opcodes are still a big mess, and shaders are one of the
most (if not the most) important parts of the interface.
For the series:
Reviewed-by: Jose Fonseca
Jose
- Original Message -
> TGSI_OPCODE_KIL and KILP had confusing names. The
I admit I haven't fully understood what's being proposed yet. But just a few
quick words.
I always wanted to have a "present" method that ensures that the contents of a
resource is made visible to whatever the consumer is (full-screen flip, blit to
primary surface, a compositor, etc.). We have
The series looks alright AFAICT.
The only request I have is the ability to disable the cache, so that we can
iron out any eventual bugs.
Another thing we eventually need to think about is thread safety. Though that's
not a new problem, so it can be addressed in a follow-on change.
Jose
-
rl?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=JXBgl5uBqvPNX%2BdbIW3nyeyaAE1k%2Fe5i%2BFx%2FJu%2Fujvs%3D%0A&s=23b3fafec3c062f542eff7bdeda679e533c99024a5f2b0708c0ee862c8342ca7
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
reedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=XsDKKn2C38Z0QNdS%2Boi50mFvk4%2BiW%2F6RaEWprRFlUxU%3D%0A&s=d876b41ad03741ecc863ed4860b4b2d7e88ce60a2b040d0f2493f3c6496ada1a
>
Reviewed-by: Jose Fonseca
___
Looks good AFAICT.
Jose
- Original Message -
> If the shader is too large, plug in a dummy shader. This patch also
> reworks the existing dummy shader code.
> ---
> src/gallium/drivers/svga/include/svga_reg.h |1 +
> src/gallium/drivers/svga/svga_state_fs.c| 60
>
Sounds great to me.
Jose
- Original Message -
> The number of allowed temporaries increases almost with every
> iteration of an api. We used to support 128, then we started
> increasing and the newer api's support 4096+. So if we notice
> that the number of temporaries is larger than our
Looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Previously, we were really doing F2I. And also move it to generic section.
> (Note that for llvmpipe the code generated is definitely bad, due to lack
> of unsigned conversions with sse. I think though what llvm
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would have
been alright if it wasn't for this bit in
http://www.opengl.org/registry/specs/AMD/pinned_memory.txt which says:
2) Can the application still use the buffer using the CPU address?
RESOLVED: YES. However,
Let's update LP_MAX_TGSI_IMMEDIATES and use it instead of 4096.
Otherwise looks good.
Jose
- Original Message -
> We need to handle a lot more immediates and in order to do that
> we also switch from allocating this structure on the stack to
> allocating it on the heap.
>
> Signed-off-
ureg_tokens {
> #define UREG_MAX_SYSTEM_VALUE PIPE_MAX_ATTRIBS
> #define UREG_MAX_OUTPUT PIPE_MAX_SHADER_OUTPUTS
> #define UREG_MAX_CONSTANT_RANGE 32
> -#define UREG_MAX_IMMEDIATE 256
> +#define UREG_MAX_IMMEDIATE 4096
> #define UREG_MAX_ADDR 2
> #define UREG_MAX_PRED 1
>
- Original Message -
> On 05.02.2014 18:08, Jose Fonseca wrote:
> > I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would
> > have been alright if it wasn't for this bit in
> > https://urldefense.proofpoint.com/v1/url?u=http://ww
n Wed, Feb 5, 2014 at 11:53 AM, Grigori Goronzy wrote:
>
> > On 05.02.2014 18:08, Jose Fonseca wrote:
> >
> >> I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
> >> would have been alright if it wasn't for this bit in
> &
- Original Message -
>
>
> - Original Message -
> > On 05.02.2014 18:08, Jose Fonseca wrote:
> > > I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
> > > would
> > > have been alright if it wasn't for th
the GPU address space permanently, while
> ARB_buffer_storage allows mapping GPU memory to the CPU address
> permanently. At the end of the day, both the GPU and the CPU can read
> and modify the same buffer and all they need to use for
> synchronization is fences.
>
> Marek
>
>
Series looks good to me. Thanks for the nice cleanup.
Jose
- Original Message -
> The _glthread_GetID() function is also defined in mapi_glapi.c
> ---
> src/mapi/glapi/Makefile.sources | 1 -
> src/mapi/glapi/SConscript | 1 -
> src/mapi/glapi/glthread.c | 7 ---
- Original Message -
> On Mon, 2014-03-03 at 21:41 +, jfons...@vmware.com wrote:
> > From: José Fonseca
>
> I think the commit summary should say 'nano to millisecond'?
Indeed. Thanks.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesk
Looks good.
Adding a few assertions before dereferencing these arrays might come handy in
the future.
Jose
- Original Message -
> Because in draw we always inject position at slot 0 whenever
> fragment shader would take the maximum number of inputs (32) it
> meant that we had PIPE_MAX_A
Makes sense. Good catch.
BTW, both changes seem candidate for stable branch.
Jose
- Original Message -
> draw_current_shader_* functions return a final output when considering
> both the geometry shader and the vertex shader. But when code generating
> vertex shader we can not be using o
- Original Message -
> One thing I noticed while working on this was that we only reallocate buffer
> storage for INVALIDATE_BUFFER_BIT when UNSYNCHRONIZED_BIT is unset. The
> ARB_mbr spec says that the contents "may be discarded", not "must be
> discarded". However, while writing the gla
- Original Message -
> - Original Message -
> > One thing I noticed while working on this was that we only reallocate
> > buffer
> > storage for INVALIDATE_BUFFER_BIT when UNSYNCHRONIZED_BIT is unset. The
> > ARB_mbr spec says that the contents "may be discarded", not "must be
>
I agree that apps that only write to a buffer shouldn't use both
MAP_UNSYNCHRONIZED and MAP_INVALIDATE_BUFFER_BIT, if that's your point. Apps
should stick so a single strategy. But it seems a common pitfall.
Note that MAP_INVALIDATE_*_BIT purpose is not just avoid synchronization. They
also a
rs/dri/radeon/radeon_fbo.c
> @@ -783,8 +783,7 @@ radeon_render_texture(struct gl_context * ctx,
> return;
> }
>
> - DBG("Begin render texture tid %lx tex=%u w=%d h=%d refcount=%d\n",
> - _glthread_GetID(),
> + DBG("Begin render texture tex=%u w=%d h=%d refcount=%d\n",
> att->Texture->Name, newImage->Width, newImage->Height,
> rb->RefCount);
>
> --
> 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 03/06/2014 09:59 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > With the recent SRGB changes all my automated OpenGL llvmpipe tests
> > (piglit, conform, glretrace) start asserting with the backtrace below.
> >
> > I'm hoping this change will fix
- Original Message -
>
>
> - Original Message -
> > On 03/06/2014 09:59 AM, jfons...@vmware.com wrote:
> > > From: José Fonseca
> > >
> > > With the recent SRGB changes all my automated OpenGL llvmpipe tests
> > > (piglit, conform, glretrace) start asserting with the backtrace
- Original Message -
> Am 06.03.2014 18:32, schrieb Jose Fonseca:
> >
> >
> > - Original Message -
> >>
> >>
> >> - Original Message -
> >>> On 03/06/2014 09:59 AM, jfons...@vmware.com wrote:
> >>>
- Original Message -
> To match PIPE_FORMAT_R8G8B8A8_SRGB.
> ---
> src/mesa/main/format_pack.c | 27 +++
> src/mesa/main/format_unpack.c| 14 ++
> src/mesa/main/formats.c | 15 +++
> src/mesa/main/formats.h
- Original Message -
> On 03/07/2014 09:45 AM, Roland Scheidegger wrote:
> > Am 07.03.2014 05:47, schrieb Chia-I Wu:
> >> On Fri, Mar 7, 2014 at 11:56 AM, Chia-I Wu wrote:
> >>> On Fri, Mar 7, 2014 at 2:04 AM, Jose Fonseca wrote:
> >>
601 - 700 of 2351 matches
Mail list logo
