Correctly set _BaseFormat field when creating a gl_renderbuffer
with EGLImage storage.
Signed-off-by: Frank Henigman
Reviewed-by: Stéphane Marchesin
---
src/mesa/drivers/dri/i915/intel_fbo.c | 3 +--
src/mesa/drivers/dri/i965/intel_fbo.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions
ba8_permutation \
> + *(__m128i *)(dst) = _mm_shuffle_epi8(\
> + (__m128i) _mm_loadu_ps((float*)(src)), \
> + *(__m128i *) rgba8_permutation\
> )
> #endif
>
> --
> 1.8.3.2
>
Reviewed-by: Frank Henigma
Force C++ linking of i965_dri.so by adding a dummy C++ source file.
---
src/mesa/drivers/dri/i965/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/Makefile.am
b/src/mesa/drivers/dri/i965/Makefile.am
index dc140df..77670ef 100644
--- a/src/mesa/drivers/dri/
This lets me remove a dlopen("libglapi.so") hack from chrome, and
avoid adding one to waffle, yay.
I suspect a lot people were forced into the dlopen hack, a quick
search found a few, see
https://bugs.freedesktop.org/show_bug.cgi?id=57702
Tested-by: Frank Henigman
On Sat, Oct 25, 201
glapi.a(glapi_libglapi_la-glapi_getproc.o):glapi_getproc.c:static_functions:
error: undefined reference to 'glDeleteTexturesEXT'
...
On Thu, Oct 30, 2014 at 5:20 PM, Frank Henigman wrote:
> This lets me remove a dlopen("libglapi.so") hack from chrome, and
> avoid adding one to waffle,
From: Frank Henigman
Dri driver libs are not linked to pull in libglapi so gbm_create_device()
fails when it tries to dlopen them (unless the application is linked
with something that does pull in libglapi, like libGL).
Until dri drivers can be fixed properly, dlopen libglapi before trying
to
On Thu, Nov 6, 2014 at 8:09 AM, Emil Velikov wrote:
> Indeed. static-glapi does not get too much testing, plus it seems that
> it's broken (in a way) for a lng time.
> It seems that we'll have to (temporary) resolve with shoving
> dlopen(libglapi.so) into gbm, so that in time programs can nuk
I tested your patch with the "teximage" program in mesa demos, the
same thing I used to benchmark when I developed this code.
As Matt and Chad point out, the odd-looking _faster functions are
there for a reason. Your change causes a huge slowdown.
I tested on a sandybridge system with a "Intel(R)
On Thu, Nov 6, 2014 at 7:30 PM, Frank Henigman wrote:
> Also I couldn't configure the build after your patch. I think you
> left out a change to configure.ac to define SSSE3_SUPPORTED.
Ah, that was in patch 1/2.
___
mesa-dev mailing li
On Sat, Nov 8, 2014 at 7:13 PM, Emil Velikov wrote:
> On 06/11/14 21:29, Frank Henigman wrote:
>> From: Frank Henigman
>>
>> Dri driver libs are not linked to pull in libglapi so gbm_create_device()
>> fails when it tries to dlopen them (unless the application is li
The name "surfaceless" suits me.
Does this platform need to provide a hint to the user about buffer format?
Platform drm does this via the EGL_NATIVE_VISUAL_ID query of
eglGetConfigAttrib(), returning a gbm format value. Unless we do the
same or similar here, how does the user robustly find the r
On Wed, Apr 8, 2015 at 1:28 AM, Chad Versace wrote:
> On Tue 07 Apr 2015, Kristian Høgsberg wrote:
>>
>> On Tue, Apr 7, 2015 at 6:46 PM, Frank Henigman
>> wrote:
>>>
>>> The name "surfaceless" suits me.
>>>
>>> Does this
If a precision qualifer is allowed on type T, it should be allowed
on an array of T. Refactor the check to ensure this is the case.
---
I wanted to expand the comment to say why is_record() is in there,
but I don't understand why it is. I thought structs couldn't have
precision qualifiers.
src/
validate_uniform_parameters so the bounds checks there became
redundant and were removed.
The test in glGetUniformLocation is modified to check array bounds
so it now returns GL_INVALID_INDEX (-1) if you ask for the location
of a non-existent array element, as it should.
Signed-off-by: Frank Henigman
get
transformed to the same as above and then the assertion would fail:
for (int i = 0; i < 2; ++i) a += u[i];
This patch changes the assertion failure to a compile failure.
https://bugs.freedesktop.org/show_bug.cgi?id=59429
Signed-off-by: Frank Henigman
---
src/mesa/drivers/dri/i
Set fs_visitor::params_remap to NULL in the constructor.
This variable was potentially tested in fs_visitor::remove_dead_constants()
before being set.
Signed-off-by: Frank Henigman
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa
On Mon, Jan 28, 2013 at 9:50 PM, Ian Romanick wrote:
> On 01/28/2013 05:06 PM, Frank Henigman wrote:
>
>> An assertion in fs_visitor::remove_dead_**constants() would fail on
>> code like this, which accesses a non-existent uniform:
>>uniform vec u[1];
>>
I see in the list archives that gprof support was pulled a few years ago.
Anyone remember why? Is there any chance of working today?
I tried compiling with -pg but haven't manage to get any profiling info yet.
Thanks.
___
mesa-dev mailing list
mesa-dev@l
validate_uniform_parameters now checks that the array index is
valid. This means if an index is out of bounds, glGetUniform* now
fails with GL_INVALID_OPERATION, as it should.
_mesa_uniform and _mesa_uniform_matrix also call
validate_uniform_parameters so the bounds checks there became
redundant a
:
> On 11/02/2012 01:12 PM, Frank Henigman wrote:
>
>> validate_uniform_parameters now checks that the array index is
>> valid. This means if an index is out of bounds, glGetUniform* now
>> fails with GL_INVALID_OPERATION, as it should.
>> _mesa_un
New piglit test:
http://lists.freedesktop.org/archives/piglit/2012-November/003690.html
On Mon, Nov 5, 2012 at 12:04 PM, Frank Henigman wrote:
> Should have mentioned it does pass piglit, but now that I look I don't see
> any tests generating an out-of-bounds array index. I also
21 matches
Mail list logo
