This (very tiny) patch fixes the bug (#72264) where when
no matching function call was found the error message
gave the line and column number as 0.
---
src/glsl/ast_function.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ast_function.cpp
To help the transition period when DRI loaders are being updated
to support the newer __driDriverExtensions_foo mechanism,
we populate __DRIextension with the extensions returned
by __driDriverExtensions_foo during a library contructor
function.
We find the driver foo's name by using the dladdr
Paul Berry stereotype...@gmail.com writes:
[...]
This order of patches introduces temporary build breakages, which I'd
prefer to avoid if possible. Here's one order which I've verified works
(there may be other possibilities):
[PATCH 03/11] mesa: Add state data structures requried for
Chris Forbes chr...@ijw.co.nz writes:
[...]
@@ -4662,6 +4673,7 @@ ast_process_structure_or_interface_block(exec_list
*instructions,
fields[i].interpolation =
interpret_interpolation_qualifier(qual, var_mode, state, loc);
fields[i].centroid =
Oh I wasn't aware of that extension.
It seems though those functions aren't quite ideally suited for that
neither. First, they require surfaces, whereas the OpenGL extension is
done specifically so the texture may be cleared even if the texture is
non-renderable (hence surface creation may fail).
We can easily change the functions, so that they take pipe_box instead
of pipe_surface. It's not a problem. The state tracker or gallium/util
will have to provide a fallback path for compressed and
non-renderable formats anyway.
Marek
On Fri, Dec 6, 2013 at 2:29 PM, Roland Scheidegger
On 24 November 2013 21:00, Francisco Jerez curroje...@riseup.net wrote:
---
src/mesa/main/config.h | 1 +
src/mesa/main/dd.h | 1 +
src/mesa/main/mtypes.h | 100
+
src/mesa/main/texobj.c | 1 +
4 files changed, 103 insertions(+)
There are a number of patches marked for stable that don't appear to
have any reviews. Most of these patches cover areas that I'm not
qualified to review, so I don't really feel comfortable cherry-picking
them over. Can I get anyone other than the patch authors to vouch for
any of these?
On 12/06/2013 12:34 AM, Kevin Rogovin wrote:
This (very tiny) patch fixes the bug (#72264) where when
no matching function call was found the error message
gave the line and column number as 0.
The commit message should describe why the change was made. This just
reiterates the problem. The
On Fri, Dec 6, 2013 at 11:19 AM, Ian Romanick i...@freedesktop.org wrote:
There are a number of patches marked for stable that don't appear to
have any reviews. Most of these patches cover areas that I'm not
qualified to review, so I don't really feel comfortable cherry-picking
them over.
On 24 November 2013 21:00, Francisco Jerez curroje...@riseup.net wrote:
Including pack/unpack and texstore code. This texture format is a
requirement for ARB_shader_image_load_store.
---
src/mesa/main/format_pack.c | 29 +++
src/mesa/main/format_unpack.c | 32
On 12/06/2013 09:21 AM, Ilia Mirkin wrote:
On Fri, Dec 6, 2013 at 11:19 AM, Ian Romanick i...@freedesktop.org wrote:
There are a number of patches marked for stable that don't appear to
have any reviews. Most of these patches cover areas that I'm not
qualified to review, so I don't really
op 06-12-13 18:45, Ian Romanick schreef:
On 12/06/2013 09:21 AM, Ilia Mirkin wrote:
On Fri, Dec 6, 2013 at 11:19 AM, Ian Romanick i...@freedesktop.org wrote:
There are a number of patches marked for stable that don't appear to
have any reviews. Most of these patches cover areas that I'm not
On Fri, Dec 6, 2013 at 4:08 AM, Michel Dänzer mic...@daenzer.net wrote:
On Don, 2013-12-05 at 18:43 +0100, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This fixes valgrind errors in glxinfo.
[...]
diff --git a/src/gallium/drivers/radeonsi/si_state.c
OK, I'd like to handle that [and any similar cases] in a follow-up
patch with some additional piglits.
-- Chris
On Sat, Dec 7, 2013 at 12:24 AM, Francisco Jerez curroje...@riseup.net wrote:
Chris Forbes chr...@ijw.co.nz writes:
[...]
@@ -4662,6 +4673,7 @@
On Fri, Dec 6, 2013 at 2:35 AM, Jordan Justen jordan.l.jus...@intel.com wrote:
To help the transition period when DRI loaders are being updated
to support the newer __driDriverExtensions_foo mechanism,
we populate __DRIextension with the extensions returned
by __driDriverExtensions_foo during
On 24 November 2013 21:00, Francisco Jerez curroje...@riseup.net wrote:
+static gl_format
+get_image_format(GLenum format)
+{
+ switch (format) {
+ case GL_RGBA32F:
+ return MESA_FORMAT_RGBA_FLOAT32;
+
+ case GL_RGBA16F:
+ return MESA_FORMAT_RGBA_FLOAT16;
+
+ case
---
src/gallium/drivers/radeon/radeon_llvm.h | 6 +++
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 43 --
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm.h
b/src/gallium/drivers/radeon/radeon_llvm.h
On 24 November 2013 21:00, Francisco Jerez curroje...@riseup.net wrote:
+enum name=VERTEX_ATTRIB_ARRAY_BARRIER_BIT value=0x0001/
+enum name=ELEMENT_ARRAY_BARRIER_BIT value=0x0002/
+enum name=UNIFORM_BARRIER_BIT value=0x0004/
+enum name=TEXTURE_FETCH_BARRIER_BIT value=0x0008/
On 6 December 2013 02:54, Francisco Jerez curroje...@riseup.net wrote:
Paul Berry stereotype...@gmail.com writes:
[...]
This order of patches introduces temporary build breakages, which I'd
prefer to avoid if possible. Here's one order which I've verified works
(there may be other
Jordan Justen jljus...@gmail.com writes:
We find the driver foo's name by using the dladdr function
which gives the path of the dynamic library's name that
was being loaded.
That sounds like all kinds of win for existing X servers. Thanks for
doing it up in style, so that a megadrivers build
On 12/05/2013 09:52 AM, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This corresponding piglit tests supported this incorrect behavior instead of
pointing at it.
See the GL 4.4 spec if the GL 3.0 spec is not clear enough.
I looked at the 4.0 spec, and I think I see where the
On 12/06/2013 01:12 PM, Jordan Justen wrote:
On Fri, Dec 6, 2013 at 2:35 AM, Jordan Justen jordan.l.jus...@intel.com
wrote:
To help the transition period when DRI loaders are being updated
to support the newer __driDriverExtensions_foo mechanism,
we populate __DRIextension with the
On Fri, Dec 6, 2013 at 3:50 PM, Ian Romanick i...@freedesktop.org wrote:
On 12/06/2013 01:12 PM, Jordan Justen wrote:
On Fri, Dec 6, 2013 at 2:35 AM, Jordan Justen jordan.l.jus...@intel.com
wrote:
To help the transition period when DRI loaders are being updated
to support the newer
The spec is cleaned up in GL 4.4 Compatibility (this is the only one I
read except GL 3.0). It doesn't mention FRONT, BACK, etc. Instead it
just says that DRAW_BUFFERi can identify one or more colorbuffers and
all of them are cleared, therefore no clarification is needed for
readers of GL 4.4.
On Fri, Dec 06, 2013 at 10:43:42PM +0100, Vincent Lejeune wrote:
---
Reviewed-by: Tom Stellard thomas.stell...@amd.com
src/gallium/drivers/radeon/radeon_llvm.h | 6 +++
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 43
--
2 files changed, 45
To help the transition period when DRI loaders are being updated
to support the newer __driDriverExtensions_foo mechanism,
we populate __DRIextension with the extensions returned
by __driDriverExtensions_foo during a library contructor
function.
We find the driver foo's name by using the dladdr
On Fri, Dec 6, 2013 at 7:11 PM, Jordan Justen jordan.l.jus...@intel.com wrote:
To help the transition period when DRI loaders are being updated
to support the newer __driDriverExtensions_foo mechanism,
we populate __DRIextension with the extensions returned
by __driDriverExtensions_foo during
On 12/06/2013 07:54 PM, Matt Turner wrote:
On Fri, Dec 6, 2013 at 7:11 PM, Jordan Justen jordan.l.jus...@intel.com
wrote:
To help the transition period when DRI loaders are being updated
to support the newer __driDriverExtensions_foo mechanism,
we populate __DRIextension with the extensions
On Fri, Dec 6, 2013 at 7:58 PM, Ian Romanick i...@freedesktop.org wrote:
This part gets build using C99, right? If so, that should be fine.
It's fine technically, but we don't use // comments in any other .c
files in i965 except for two (one added by Jordan).
Create the ref_bo without any storage type flags set for now. This can
probably be split up somehow later on, but this seems to work.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
Would be great if someone could see if this also makes MPEG4 work
31 matches
Mail list logo
