On Wed, Apr 8, 2015 at 1:28 AM, Chad Versace chad.vers...@intel.com wrote:
On Tue 07 Apr 2015, Kristian Høgsberg wrote:
On Tue, Apr 7, 2015 at 6:46 PM, Frank Henigman fjhenig...@google.com
wrote:
The name surfaceless suits me.
Does this platform need to provide a hint to the user about
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
Correctly set _BaseFormat field when creating a gl_renderbuffer
with EGLImage storage.
Signed-off-by: Frank Henigman fjhenig...@google.com
Reviewed-by: Stéphane Marchesin marc...@chromium.org
---
src/mesa/drivers/dri/i915/intel_fbo.c | 3 +--
src/mesa/drivers/dri/i965/intel_fbo.c | 2 +-
2 files
On Sat, Nov 8, 2014 at 7:13 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 06/11/14 21:29, Frank Henigman wrote:
From: Frank Henigman fjhenig...@chromium.org
Dri driver libs are not linked to pull in libglapi so gbm_create_device()
fails when it tries to dlopen them (unless
From: Frank Henigman fjhenig...@chromium.org
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
On Thu, Nov 6, 2014 at 8:09 AM, Emil Velikov emil.l.veli...@gmail.com 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
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 fjhenig...@google.com 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
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 fjhenig...@google.com
On Sat, Oct
-glapi_getproc.o):glapi_getproc.c:static_functions:
error: undefined reference to 'glDeleteTexturesEXT'
...
On Thu, Oct 30, 2014 at 5:20 PM, Frank Henigman fjhenig...@google.com wrote:
This lets me remove a dlopen(libglapi.so) hack from chrome, and
avoid adding one to waffle, yay.
I suspect a lot people were
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.
) _mm_loadu_ps((float*)(src)), \
+ *(__m128i *) rgba8_permutation\
)
#endif
--
1.8.3.2
Reviewed-by: Frank Henigman fjhenig...@google.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
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
---
On Mon, Jan 28, 2013 at 9:50 PM, Ian Romanick i...@freedesktop.org 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];
...
a += u[0] + u[1
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 fjhenig...@google.com
---
src/mesa
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 fjhenig...@google.com
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 ++
1 file changed, 2 insertions
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
...@freedesktop.org wrote:
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_uniform and _mesa_uniform_matrix also call
New piglit test:
http://lists.freedesktop.org/archives/piglit/2012-November/003690.html
On Mon, Nov 5, 2012 at 12:04 PM, Frank Henigman fjhenig...@google.comwrote:
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
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
20 matches
Mail list logo
