Looks good to me.
Jose
- Original Message -
> D3D10 allows setting of the internal offset of a buffer, which is
> in general only incremented via actual stream output writes. By
> allowing setting of the internal offset draw_auto is capable
> of rendering from buffers which have not been
mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=RJ4H8Fodtw4bz9feDaZf0Kmfgb1mRzAes7QYuQuJBIg%3D%0A&s=e1505a767e53dc4a2
How come? GLhandleARB is still a GLuint on Linux. And calling one vs the other
works just as well.
How does merely un-aliasing the entrypoints break anything?
Jose
- Original Message -
> No way. This will break existing applications on Linux.
>
> On 03/08/2014 05:10 PM, Brian Paul wr
- Original Message -
> On 03/10/2014 03:09 PM, Ian Romanick wrote:
> > On 03/10/2014 02:06 PM, Ian Romanick wrote:
> >> No way. This will break existing applications on Linux.
>
> How so? Before, for example, we had glCompileShaderARB(GLhandleARB) and
> glCompileShader(GLuint) libGL en
- Original Message -
> On 03/10/2014 02:52 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> On 03/10/2014 03:09 PM, Ian Romanick wrote:
> >>> On 03/10/2014 02:06 PM, Ian Romanick wrote:
> >>>> No way. This wi
Looks good.
This is yet another thing that would benefit if we moved things like
u_debug.h's assert to a place it can be used everywhere -- the "shared runtime"
idea.
Jose
- Original Message -
> In the gallium code, the assert() macro could come from either the
> system's assert.h file
Series looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> The conversion code for srgb was tuned for n x 4x8bit AoS -> 4 x nxfloat SoA
> (and vice versa), fix this to handle also 16bit 565-style srgb formats.
> Still not really all that generic, things like r10g1
- Original Message -
> On 03/24/2014 09:31 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > As done in draw_pipe_aaline and draw_pipe_aapoint modules.
> > ---
> > src/gallium/auxiliary/draw/draw_pipe_pstipple.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
>
assert(num_dsts == 1);
> + /* "Conversion" must be N:N */
> + assert(num_srcs == num_dsts);
>
> - tmp[0] = src[0];
> + for(i = 0; i < num_dsts; ++i)
> + tmp[i] = src[i];
> }
>
> for(i = 0; i < num_dsts; ++i)
> --
> 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
- Original Message -
> On 03/25/2014 09:34 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > It is quite hard to meet the dependency of the libxml2 python bindings
> > out side Linux, and in particularly on MacOSX; whereas ElementTree is
> > part of Python's standard library.
I see the crashes you're referring to.
I don't quite understand why though: concerning the geometry shader, other than
cosmetic changes, in theory I should just have replaced a null/non-null
`tokens` pointer with a boolean `no_tokens`, though obviously I missed
something.
I should also had bro
gt;state.sw.ve_format[i] == SVGA3D_DECLTYPE_MAX) {
> /* Unsupported format - use software fetch */
> need_swvfetch = TRUE;
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=bUFb65CGw9qnIKJ%2B4A%2FetCzS4sUJZr5stYFdvN%2FmhNM%3D%0A&s=ebed37f07052b55f47dc46ced85bbcb2defd223ee03a071dfc085e9b550777dc
>
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 -
> > I see the crashes you're referring to.
> >
> > I don't quite understand why though: concerning the geometry shader, other
> > than cosmetic changes, in theory I should just have replaced a
> > null/non-null
> > `tokens` pointer with a boolean `no_tokens`, though ob
Series looks good to me.
Jose
- Original Message -
> it's useful to know what the llvmbuildstore arguments are going to
> be before executing it because it can crash and make sure to
> print out the inputs only if we're not generating a gs because
> it fetches inputs differently.
>
> Sig
LGTM.
Jose
- Original Message -
> The underlying glDrawArrays() calls weren't getting compiled into
> the display list. We simply need to use the current dispatch table
> so the CALL_DrawArrays() is routed to the display list save function.
>
> This patch also fixes glMultiModeDrawArray
- Original Message -
> On Wed, Mar 26, 2014 at 4:30 AM, Roland Scheidegger
> wrote:
> > Am 26.03.2014 03:29, schrieb Marek Olšák:
> >> My reasoning was that it would be better to specify a raw clear value
> >> and clear value size for buffers, which are always untyped, and
> >> pipe_colo
Reviewed-by: Jose Fonseca
On 01/12/14 20:37, Brian Paul wrote:
The pipe-loader code wasn't finding util/u_atomic.h
---
src/gallium/auxiliary/pipe-loader/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/auxiliary/pipe-loader/Makefile.am
b/src/gallium/auxi
Series sort of sounds sensible but it's really outside my expertise.
Zack would be a much better reviewer.
This should be thoroughly tested too.
Jose
On 02/12/14 01:31, srol...@vmware.com wrote:
From: Roland Scheidegger
The prim assembler may change the prim type when injecting prim ids now
LGTM.
On 02/12/14 16:43, Brian Paul wrote:
height=0 is legal for 1D array textures (as height=0 is legal for
I think you mean "as depth=0 is legal for 2D arrays"
2D arrays). Fixes new piglit ext_texture_array-errors test.
Cc: "10.3 10.4"
---
src/mesa/main/teximage.c | 2 +-
1 file chan
From: José Fonseca
Nowadays GCC assumes stack pointer is 16-byte aligned even on 32-bits,
but that is an assumption OpenGL drivers (or any dynamic library for
that matter) can affort to make as there are many closed- and open-
source application binaries out there that only assume 4-byte stack
al
On 02/12/14 21:10, Brian Paul wrote:
On 12/02/2014 01:27 PM, Jose Fonseca wrote:
From: José Fonseca
Nowadays GCC assumes stack pointer is 16-byte aligned even on 32-bits,
but that is an assumption OpenGL drivers (or any dynamic library for
that matter) can affort to make as there are many
On 03/12/14 04:50, Tom Stellard wrote:
As of r223183 EngineBuilder::setMCJITMemoryManager() takes a unique_ptr.
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gall
On 03/12/14 02:59, srol...@vmware.com wrote:
From: Roland Scheidegger
Multiple scenes per context are meant to be used so a new scene can be built
while another one is processed in rasterization. However, quite surprisingly,
this does not actually work (and according to git log, possibly never
I'm also concerned this sort of ad-hoc re-interpretation of opcode
semantics will come to bytes us later, as different state trackers might
want different semantics.
I think we might need to redefine TGSI_OPCODE_RCP opcode or introduce a
TGSI_OPCODE_RCP_LEGACY opcode.
Also, do we know exactl
I certainly don't want to deter you from pushing a quick fix now.
If possible I'd just like any further information you might have
collected while debugging this issue in the hope we can figure out a
more comprehensive solution should be.
Because I'm sure other drivers (including VMware's svg
Looks good AFAICT.
But I think we should probably swap the operands only once, in one
place, instead of having two branches for switch_order.
Jose
On 04/12/14 23:25, srol...@vmware.com wrote:
From: Roland Scheidegger
The original idea was to optimize away the condition by integrating it di
On 05/12/14 00:01, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
Cc: "10.4 10.3"
---
src/gallium/auxiliary/indices/u_primconvert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/indices/u_primconvert.c
b/src/gallium/auxiliary/indices/u_primconvert.
From: José Fonseca
Matches what u_vbuf_get_minmax_index() does.
---
src/gallium/auxiliary/indices/u_primconvert.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/indices/u_primconvert.c
b/src/gallium/auxiliary/indices/u_primconvert.c
index 4632781..eb
On 05/12/14 14:12, Ilia Mirkin wrote:
On Fri, Dec 5, 2014 at 9:10 AM, Jose Fonseca wrote:
On 05/12/14 00:01, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
Cc: "10.4 10.3"
---
src/gallium/auxiliary/indices/u_primconvert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
On 05/12/14 14:18, Ilia Mirkin wrote:
On Fri, Dec 5, 2014 at 9:16 AM, Jose Fonseca wrote:
From: José Fonseca
Matches what u_vbuf_get_minmax_index() does.
Hm, nouveau nv50 (and probably nvc0) does:
if (ib->buffer) {
nv50->idxbuf.offset = ib->offset;
default, so if you prefer that they can easily be killed, and the "if
(expr->operation == ir_binop_nequal)" should have been a ("else if
(expr->operation == ir_binop_nequal)" indeed.)
Roland
Am 05.12.2014 um 13:01 schrieb Jose Fonseca:
Looks good AFAICT.
But I think w
I'm not particularly knowledgeable about autoconf/make, but it looks
correct AFAICT. Thanks for doing this.
I think it would be useful to also add a comment somewhere on why
-mstackrealign is necessary for 32-bits, for future reference.
Reviewed-by: Jose Fonseca
Jose
On 07/12/14
I never tried, but it doesn't surprise that ?USE_MGL_NAMESPACE doesn't work
properly on Windows.
At very least the src/mesa/drivers/windows/gdi and
src/gallium/targets/libgl-gdi targets will fail because the .DEF files there
explicitly request the non-mangled symbols.
Not sure if src/mesa/dr
On 09/12/14 11:28, Marek Olšák wrote:
From: Marek Olšák
It's exposed, because I plan to use it elsewhere later.
I hesitate in repeating myself, but I can't close my eyes. This is such
a bad idea, at so many levels.
How will this cope when the application is running on a different
locale,
On 11/12/14 08:40, Emil Velikov wrote:
Hi Jose,
On 10/12/14 14:18, Jose Fonseca wrote:
I never tried, but it doesn't surprise that ?USE_MGL_NAMESPACE doesn't work
properly on Windows.
At very least the src/mesa/drivers/windows/gdi and
src/gallium/targets/libgl-gdi targets will fa
Overall I think this is a great cleanup.
Just a remark about the chosen names.
On 10/12/14 21:22, srol...@vmware.com wrote:
From: Roland Scheidegger
Plus a new PIPE_CAP_VERTEXID_NOOFFSET query.
"Vertex offset" and "base vertex" are difference concepts, so I'd rather
not mix them up.
Including system's headers inside extern "C" { ... } is not safe, as system
headers may have C++ code in them, and C++ code inside extern "C" { .. }
doesn't work.
This is because putting code inside extern "C" won't make __plusplus define go
away, that is, the headers being included thinks is
From: José Fonseca
This is just to help repro and fixing these issues with any C++ compiler --
commiting this will of course wait until all issues are addressed.
$ scons src/glsl/
scons: Reading SConscript files ...
Checking for GCC ... yes
Checking for Clang ... no
Checking for X11 (x11 xex
OK. I found a way to make it easier to trap this sort of issues going forward,
regardless of compiler. See patch I just posted.
Jose
From: Brian Paul
Sent: 11 December 2014 22:05
To: mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca
Subject: Re: [Mesa
On 11/12/14 22:02, Brian Paul wrote:
On 12/11/2014 02:51 PM, Carl Worth wrote:
From: Kristian Høgsberg
The upcoming shader cache uses the SHA-1 algorithm for cryptographic
naming. These new mesa_sha1 functions are implemented with the nettle
library.
---
This patch is another in support of my
From: José Fonseca
f0ba7d897d1c22202531acb70f134f2edc30557d made debug_assert()/assert()
unsafe for expressions, but only now with u_atomic.h started to rely on
them for Windows this became an issue.
This fixes non-debug builds with MSVC.
---
src/gallium/auxiliary/util/u_debug.h | 2 +-
1 file
Series looks nice cleanup.
I don't know of any need to keep support for older GCC neither.
But I don't think it makes sense to mess with gtest -- it's better to
keep this in sync with upstream, and clobber with new upstream versions
when appropriate.
All other changes are
Re
On 12/12/14 16:30, Patrick Baggett wrote:
On Fri, Dec 12, 2014 at 10:17 AM, Roland Scheidegger mailto:srol...@vmware.com>> wrote:
Am 12.12.2014 um 15:09 schrieb Jose Fonseca:
> From: José Fonseca mailto:jfons...@vmware.com>>
>
> f0ba7d897d1c22202531acb7
int n,
unsigned int reg)
static float
ra_get_spill_benefit(struct ra_graph *g, unsigned int n)
{
- int j;
+ unsigned int j;
float benefit = 0;
int n_class = g->nodes[n].class;
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
m
On 12/12/14 20:38, Matt Turner wrote:
José,
As it is now, since we're not building the gbm or egl state trackers
via autotools, they're not included in the tarball created by make
dist. That is, the files in
src/gallium/state_trackers/egl
src/gallium/state_trackers/gbm
wouldn't be distributed.
On 12/12/14 20:59, Matt Turner wrote:
On Fri, Dec 12, 2014 at 12:54 PM, Jose Fonseca wrote:
On 12/12/14 20:38, Matt Turner wrote:
José,
As it is now, since we're not building the gbm or egl state trackers
via autotools, they're not included in the tarball created by make
dist. Th
#ifdef __cplusplus
+extern "C" {
+#endif
+
+
/**
* \name Internal functions
*/
@@ -212,4 +217,9 @@ _mesa_InvalidateTexImage(GLuint texture, GLint level);
/*@}*/
+#ifdef __cplusplus
+}
+#endif
+
+
#endif
Thanks for doing this, Brian. I was about to do it myself.
Series is
gather(struct lp_build_context *bld,
LLVMBuilderRef builder = bld->gallivm->builder;
LLVMValueRef res = bld->undef;
unsigned i;
- LLVMValueRef temp_ptr;
+ LLVMValueRef temp_ptr = NULL;
if (overflow_mask) {
temp_ptr = lp_build_alloca(
Reviewed-b
IIUC, "ancillary" here means depth/stencil buffer associated with the
framebuffer.
So basically PIPE_FLUSH_INVALIDATE_ANCILLARY you're proposing will
invalidate the currently bound pipe_framebuffer_state::zsbuf.
I think we eventually will want a more general invalidate pipe_context
method,
Do we really need a new pipe_context::set_counter_buffer method?
Shouldn't this case be covered by pipe_context::set_shader_resources ?
If we really need new method, I'd like we have better names for them, so
we can clearly distinguish them.
IIUC GL_ARB_shader_atomic_counters correctly, this
evel/last_level/ first_layer/last_layer as structure pointer
parameter, instead of requiring actual views. Which can be done later,
so I suppose this is fine like this.
Reviewed-by: Jose Fonseca
Jose
---
src/gallium/include/pipe/p_context.h | 11 +++
src/gallium/sta
On 08/12/14 19:56, Matt Turner wrote:
See commit 2b7a972e for the Coccinelle script.
[...]
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 4f5a2d1..6945c2f 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -94,7 +94,7 @@ _mesa_align_malloc(size_t bytes,
_assignment *ir)
new_inst->saturate = inst->saturate;
inst->dead_mask = inst->dst.writemask;
} else {
- emit_block_mov(ir, ir->rhs->type, &l, &r);
+ emit_block_mov(ir, ir->rhs->type, &l, &r, NULL, false);
}
}
Looks good to me.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 07/01/15 19:11, Carl Worth wrote:
On Wed, Jan 07 2015, Jose Fonseca wrote:
I lost bit track of email over the Christmas period. Just noticed I had
flagged this one for replay. Sorry.
No worries. Thanks for following up now. :-)
Do you still need me to test anything on Windows? If so are
From: José Fonseca
Trivial.
---
src/mesa/main/imports.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 6945c2f..4f5a2d1 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -94,7 +94,7 @@ _mesa_alig
From: José Fonseca
We never used ulVersion for proper version checks.
Most 3rd party drivers use version 1, but recently NVIDIA OpenGL driver
started using a version number 1, so the handy trick of renaming Mesa's
ICDs as nvoglv32.dll on Windows machines with NVIDIA hardware for quick
testing of
On 08/01/15 16:57, Brian Paul wrote:
On 01/08/2015 09:41 AM, Jose Fonseca wrote:
From: José Fonseca
We never used ulVersion for proper version checks.
Most 3rd party drivers use version 1, but recently NVIDIA OpenGL driver
started using a version number 1,
What version did they use before
width, height, 1, format,
type, pixels, true);
- pixels += _mesa_image_image_stride(&ctx->Unpack, width, height,
-format, type);
+ pixels = (GLubyte *) pixels + rowStride;
}
}
else {
Looks good to me. S
Iago, Jason,
There seems to be some bad or missing dependency when building with
automake. I have a build bot that roughly does this every time:
git clean -fdx
mkdir -p build
cd build
../autogen.sh --prefix=/usr --enable-debug --enable-dri3
--enable-gles1 --enable-gles2 --enable-xa -
On 12/01/15 12:32, Iago Toral Quiroga wrote:
Hi Jose,
thanks for reporting this.
On lun, 2015-01-12 at 12:18 +, Jose Fonseca wrote:
Iago, Jason,
There seems to be some bad or missing dependency when building with
automake. I have a build bot that roughly does this every time:
git
| 2 +-
src/mesa/state_tracker/st_program.c | 2 +-
src/mesa/vbo/vbo_exec_array.c | 3 ++-
src/util/hash_table.c | 2 +-
30 files changed, 56 insertions(+), 57 deletions(-)
Thanks for this cleanup.
Series looks good AFAICT.
Reviewed-by: Jose Fonseca
On 15/01/15 15:39, Jason Ekstrand wrote:
I just pushed NIR to master. I wanted to write a couple of notes about
the interaction between that code and MSVC and what the current plan
is. Right now, NIR won't build with MSVC; at least not MSVC 2010 (or is
it 11?) as it uses quite a bit of C99. It
Yes, the bit shifting can be a crude approximation.
llvmpipe did that everywhere but we had to fix it in a few places, e.g.:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1569b3e536da9337a28a16d0cc6ed07043bf094b
The multiplication is unavoidable (*), but one can avoid the division of
(2*n
doing.
In that case maybe it would be better to leave the code as it is so that
it's a bit easier to understand.
- Neil
Jose Fonseca writes:
Yes, the bit shifting can be a crude approximation.
llvmpipe did that everywhere but we had to fix it in a few places, e.g.:
https://urldefens
On 15/01/15 19:46, Carl Worth wrote:
On Thu, Jan 08 2015, Jose Fonseca wrote:
Note that Windows build is only supported with SCons. Never with
autobuild.
OK. That's good for me to learn. I've requested that the folks doing our
automated build testing here will also start testing sc
From: José Fonseca
The dri2_x11_add_configs_for_visuals() function happily matches a 32
bits EGLconfig with a 24 bits X visual. However it was passing 32bits
depth to xcb_put_image(), making X server unhappy:
https://github.com/apitrace/apitrace/issues/313#issuecomment-70571911
PS: I rarely
On 11/01/2019 22:38, Matt Turner wrote:
On Fri, Jan 11, 2019 at 2:28 PM Ilia Mirkin wrote:
On Fri, Jan 11, 2019 at 5:12 PM Matt Turner wrote:
From: Gert Wollny
Since Meson will eventually be the only build system deprecate autotools
now. It can still be used by invoking configure with the
I just noticed these patches, because Appveyor build is broken, and to
my surprise, on Cygwin.
There are several problems with these patches:
- First of all, there were commited with no reviewed by. Not by me (a
quick `git log appveyor.yml` would tell you I pretty much wrote and
maitain it).
This change applies the workaround suggested by Bill Deegan on the
affected SCons versions.
It also adds a comment with the URL explaining why we were using
customizing the decider and max_drift in the first place, as I had
forgotten all about it.
Bugzilla: https://bugs.freedesktop.org/show_bug.c
k = 1 << bit;
+ const unsigned word = index / UTIL_BITMASK_BITS_PER_WORD;
+ const unsigned bit = index % UTIL_BITMASK_BITS_PER_WORD;
+ const util_bitmask_word mask = 1 << bit;
assert(bm);
Series is
Reviewed-by: Jose Fonseca
_
I have few doubts/questions.
On 05/03/2019 23:57, Brian Paul wrote:
This will allow us to query whether a context is valid.
In addition to keeping a list of contexts, we need to give each
context we create a unique ID which is never re-used. The screen
also contains a bitmask to track which ID
Did you build LLVM yourself. In my experience, passing
-DCMAKE_C_FLAGS="-g1 -fno-omit-frame-pointer" \
-DCMAKE_CXX_FLAGS="-g1 -fno-omit-frame-pointer" \
to cmake when building LLVM makes debugging info much smaller, without
compromising the ability to get stack traces, etc.
Jos
le_mtx_unlock(&stObj->validate_mutex);
}
With your upcoming change that prevents the sampler view from ever being
released with the wrong context (which I suppose should go before this
one?), this series is
Reviewed-By: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
d5a0..c5fc30c 100644
--- a/src/mesa/state_tracker/st_texture.h
+++ b/src/mesa/state_tracker/st_texture.h
@@ -57,6 +57,9 @@ struct st_sampler_view
{
struct pipe_sampler_view *view;
+ /** The context which created this view */
+ struct st_context *st;
+
/** The glsl version of the shader seen during validation */
bool glsl130_or_later;
/** Derived from the sampler's sRGBDecode state during validation */
Otherwise looks great. It's nice to finally to have a proper solution
for this long standing tricky issue!
Reviewed-by: Jose Fonseca
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
if the view's context doesn't match the current context,
ignoring the refcount.
Reviewed-by: Roland Scheidegger
Reviewed-by: Neha Bhende
Reviewed-by: Mathias Fröhlich
Reviewed-By: Jose Fonseca
---
src/mesa/state_tracker/st_cb_flush.c | 6 +++
src/m
I'm all for TGIS simplification, but I just checked, and we rely on TGSI
predicates for some of our internal state trackers. So I'll need more
time to evaluate how much effort it would be to not rely on it, and when
can it be done.
Jose
On 01/09/15 22:19, Marek Olšák wrote:
From: Marek Olšá
On the flip side, we could remove TGSI_FILE_ADDR, TGSI_OPCODE_ARL, and
TGSI_OPCODE_ARR.
We already remove all dependencies of these from our internal state tracers.
And it is trivial to do so, at least for HW with native integer support.
Jose
On 01/09/15 23:55, Jose Fonseca wrote:
I'
On 03/09/15 16:26, Tom Stellard wrote:
On Thu, Sep 03, 2015 at 06:15:26PM +0300, Oded Gabbay wrote:
round(val*dscale) produces a double result, as val and dscale are double.
However, LLVMConstInt receives unsigned long long, so there is an
implicit conversion from double to unsigned long long.
T
On 07/09/15 10:17, Jean-Sébastien Pédron wrote:
On 04.09.2015 01:37, Matt Turner wrote:
You need to test for this support in configure.ac. It's as simple as
adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
list and then a little bit of preprocessor in src/util/macros.h.
Shou
On 10/09/15 02:54, Ian Romanick wrote:
On 09/07/2015 06:54 AM, Jose Fonseca wrote:
On 07/09/15 10:17, Jean-Sébastien Pédron wrote:
On 04.09.2015 01:37, Matt Turner wrote:
You need to test for this support in configure.ac. It's as simple as
adding a call to AX_GCC_FUNC_ATTRIBUTE i
On 11/09/15 00:35, Erik Faye-Lund wrote:
On Mon, Sep 7, 2015 at 3:54 PM, Jose Fonseca wrote:
On 07/09/15 10:17, Jean-Sébastien Pédron wrote:
On 04.09.2015 01:37, Matt Turner wrote:
You need to test for this support in configure.ac. It's as simple as
adding a call to AX_GCC_FUNC_ATTR
This state is ignored by most gallium drivers.
I also don't know of any D3D9 application that relies on
D3DRS_LASTPIXEL. And even WHCK itself doesn't seem to test it.
---
src/gallium/state_trackers/nine/nine_pipe.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/state_trackers/nin
Altough SVGA3D_RS_LASTPIXEL renderstate exists, most backends ignore it.
---
src/gallium/drivers/svga/svga_context.h | 1 -
src/gallium/drivers/svga/svga_pipe_rasterizer.c | 1 -
src/gallium/drivers/svga/svga_state_rss.c | 2 +-
3 files changed, 1 insertion(+), 3 deletions(-)
diff -
---
src/gallium/drivers/ilo/ilo_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/ilo/ilo_state.c
b/src/gallium/drivers/ilo/ilo_state.c
index d89765a..d50d5c4 100644
--- a/src/gallium/drivers/ilo/ilo_state.c
+++ b/src/gallium/drivers/ilo/ilo_state.c
@
This state has been de-fact ignored all along.
---
src/gallium/auxiliary/hud/hud_context.c| 1 -
src/gallium/auxiliary/util/u_dump_state.c | 1 -
src/gallium/docs/source/cso/rasterizer.rst | 4
src/gallium/drivers/trace/tr_dump_state.c | 1 -
src/gallium/include/pipe/p_state.h |
---
src/gallium/drivers/nouveau/nv50/nv50_state.c | 3 ---
src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 1 -
2 files changed, 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state.c
b/src/gallium/drivers/nouveau/nv50/nv50_state.c
index 410e631..76c3508 100644
--- a/src/galli
feature, so it could be implemented there.
What is the policy for removing gallium features ?
Even though there is no real support for it is, it doesn't seem a
feature that can be emulated with other features.
Yours,
Axel Davy
On 14/09/2015 13:09, Jose Fonseca wrote :
Altough SVG
On 16/09/15 14:04, Thomas Hellstrom wrote:
XA has been using L8_UNORM for a8 and yuv component surfaces.
This commit instead makes XA prefer R8_UNORM since it's assumed to have a
higher availability.
Also neither of these formats are suitable as destination formats using
destination alpha blendi
On 17/09/15 10:58, Thomas Hellstrom wrote:
On 09/17/2015 11:53 AM, Thomas Hellstrom wrote:
On 09/17/2015 11:34 AM, Jose Fonseca wrote:
On 16/09/15 14:04, Thomas Hellstrom wrote:
XA has been using L8_UNORM for a8 and yuv component surfaces.
This commit instead makes XA prefer R8_UNORM since
, atopreverse and xor seem to work fine
with a8 destiation.
v2: Fix a copy-paste error.
Reported-by: Jose Fonseca
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_composite.c | 34
src/gallium/state_trackers/xa/xa_renderer.c | 6 +++--
2 files
On 24/09/15 19:01, Marek Olšák wrote:
On Wed, Sep 2, 2015 at 12:55 AM, Jose Fonseca wrote:
I'm all for TGIS simplification, but I just checked, and we rely on TGSI
predicates for some of our internal state trackers. So I'll need more time
to evaluate how much effort it would be to n
On 28/09/15 09:09, Samuel Iglesias Gonsalvez wrote:
Fix SCons MinGW build error:
Compiling src/mesa/main/shader_query.cpp ...
src/mesa/main/shader_query.cpp: In function ‘char* get_top_level_name(const
char*)’:
src/mesa/main/shader_query.cpp:841:34: error: ‘strndup’ was not declared in
this sc
On 27/09/15 19:14, Marek Olšák wrote:
Hi,
For some reason, st/mesa assumes that shaders can't be shared by
multiple contexts and therefore has a context pointer in shader keys.
I'd like to get rid of this dependency, because there is no reason why
shaders would need to be tied to a context. In f
On 28/09/15 14:51, Marek Olšák wrote:
On Mon, Sep 28, 2015 at 2:55 PM, Jose Fonseca wrote:
On 27/09/15 19:14, Marek Olšák wrote:
Hi,
For some reason, st/mesa assumes that shaders can't be shared by
multiple contexts and therefore has a context pointer in shader keys.
I'd like to
Looks great Samuel.
Just minor suggestions.
Either way:
Reviewed-by: Jose Fonseca
On 28/09/15 15:19, Samuel Iglesias Gonsalvez wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92124
Cc: Jose Fonseca
---
I tested it on MSVC but not MinGW. I hope I did not something wrong
On 28/09/15 21:21, Marek Olšák wrote:
On Mon, Sep 28, 2015 at 9:28 PM, Jose Fonseca wrote:
On 28/09/15 14:51, Marek Olšák wrote:
On Mon, Sep 28, 2015 at 2:55 PM, Jose Fonseca wrote:
On 27/09/15 19:14, Marek Olšák wrote:
Hi,
For some reason, st/mesa assumes that shaders can't be s
On 28/09/15 15:30, Rob Clark wrote:
On Mon, Sep 28, 2015 at 8:55 AM, Jose Fonseca wrote:
I see only 2 options out of this:
1) Removing the context pointer from the shader keys. If drivers need
this, they should handle it by themselves. This will simplify st/mesa,
because TCS, TES, GS won&#
calloc(n + 1, sizeof(char));
if (!ptr)
return NULL;
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 06/10/15 20:30, Ian Romanick wrote:
On 10/06/2015 12:04 PM, Matt Turner wrote:
On Sat, Oct 3, 2015 at 5:19 PM, Jan Vesely wrote:
Signed-off-by: Jan Vesely
---
include/c11/threads_posix.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/c11/threads_posix.h b/include/c11/
On 21/12/15 22:35, Marek Olšák wrote:
Hi,
This patch series adds more flexibility to u_upload_mgr. First, it adds the
ability to specify the alignment per suballocation. The idea is that several
users can use the same upload buffer, but each may need a different alignment.
Finally, it allows
701 - 800 of 2351 matches
Mail list logo
