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
Cc: "10.0"
---
Would be great if someone could see if this also makes MPEG4 work on NVA3+. In
order to do that, remove the if (chipset
On Fri, Dec 6, 2013 at 7:58 PM, Ian Romanick 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).
___
mesa-de
On 12/06/2013 07:54 PM, Matt Turner wrote:
> On Fri, Dec 6, 2013 at 7:11 PM, Jordan Justen
> 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 __d
On Fri, Dec 6, 2013 at 7:11 PM, Jordan Justen 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 a library contructor
>
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 fu
On Fri, Dec 06, 2013 at 10:43:42PM +0100, Vincent Lejeune wrote:
> ---
Reviewed-by: Tom Stellard
> src/gallium/drivers/radeon/radeon_llvm.h | 6 +++
> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 43
> --
> 2 files changed, 45 insertions(+), 4 deletions(
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. Some
On Fri, Dec 6, 2013 at 3:50 PM, Ian Romanick wrote:
> On 12/06/2013 01:12 PM, Jordan Justen wrote:
>> On Fri, Dec 6, 2013 at 2:35 AM, Jordan Justen
>> wrote:
>>> To help the transition period when DRI loaders are being updated
>>> to support the newer __driDriverExtensions_foo mechanism,
>>> we
On 12/06/2013 01:12 PM, Jordan Justen wrote:
> On Fri, Dec 6, 2013 at 2:35 AM, Jordan Justen
> 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 _
On 12/05/2013 09:52 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> 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 initial confusi
Jordan Justen 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 can actually
On 6 December 2013 02:54, Francisco Jerez wrote:
> Paul Berry 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] me
On 24 November 2013 21:00, Francisco Jerez wrote:
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + value="0x8F39"/>
> +
> +
> +
> +
>
I'm surprised to see IMAGE_BINDING_LAYERED_EXT here instead of
IMAGE_BINDING_LAYER. I assume this was just a typographical error?
Change this line to
---
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
inde
On 24 November 2013 21:00, Francisco Jerez 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 GL_RG32F:
> +
On Fri, Dec 6, 2013 at 2:35 AM, Jordan Justen 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 a library contructor
>
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 wrote:
> Chris Forbes writes:
>>[...]
>> @@ -4662,6 +4673,7 @@ ast_process_structure_or_interface_block(exec_list
>> *instructions,
>
On Fri, Dec 6, 2013 at 4:08 AM, Michel Dänzer wrote:
> On Don, 2013-12-05 at 18:43 +0100, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> This fixes valgrind errors in glxinfo.
>
> [...]
>
>> diff --git a/src/gallium/drivers/radeonsi/si_state.c
>> b/src/gallium/drivers/radeonsi/si_state.c
>> index
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 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
On 12/06/2013 09:21 AM, Ilia Mirkin wrote:
> On Fri, Dec 6, 2013 at 11:19 AM, Ian Romanick 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
On 24 November 2013 21:00, Francisco Jerez 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 Fri, Dec 6, 2013 at 11:19 AM, Ian Romanick 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. Can I get anyone ot
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. T
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?
c45cf61
On 24 November 2013 21:00, Francisco Jerez 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(+)
>
> diff --git a/
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 wrote:
> O
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).
S
Chris Forbes 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 = qual->flags.q.centroid ? 1
Paul Berry 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
> ARB_shader_image_load
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 fu
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 b/src/glsl/ast_function
31 matches
Mail list logo
