Hi,
2014-09-09 10:56 GMT+02:00 Gwenole Beauchesne :
> This allows for importing foreign buffers in RGB32 native endian
> byte order, i.e. DRM_FORMAT_XBGR, and DRM_FORMAT_ABGR.
>
> Signed-off-by: Gwenole Beauchesne
> ---
> src/mesa/drivers/dri/i965/intel_screen.c |6 ++
> 1 file c
From: Richard Sandiford
MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM
while MESA_FORMAT_R8G8B8X8_SRGB used a function called unpack_R8G8B8X8_SRGB.
This patch renames the SNORM function to have the same order as the
MESA_FORMAT name, like the SRGB function does.
Signed-o
From: Richard Sandiford
The function was using the "X" component as the alpha channel,
rather than setting alpha to 1.0.
Signed-off-by: Richard Sandiford
Reviewed-by: Brian Paul
Signed-off-by: Dave Airlie
---
src/mesa/main/format_unpack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Richard Sandiford
MESA_FORMAT_LnAn puts the luminance in the least significant part of
the containing integer, which is equivalent to PIPE_FORMAT_LAnn.
PIPE_FORMAT_LnAn puts the luminance first in memory.
This patch fixes up the mesa<->gallium mapping accordingly.
Signed-off-by: Richard S
From: Richard Sandiford
The associated UNORM format already existed.
This means that each LnAn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
[airlied: rebased onto current master]
Signed-off-by: Richard Sandiford
Reviewed-by: Brian Paul
From: Richard Sandiford
...i.e. formats in which the first listed component is in the least
significant half of the integer.
Signed-off-by: Richard Sandiford
Reviewed-by: Brian Paul
Signed-off-by: Dave Airlie
---
src/gallium/include/pipe/p_format.h | 32
1 fi
From: Richard Sandiford
...i.e. formats in which the first listed component is in the least
significant byte of the integer. The corresponding UNORM aliases already exist.
Signed-off-by: Richard Sandiford
Signed-off-by: Dave Airlie
---
src/gallium/include/pipe/p_format.h | 24 +++
From: Richard Sandiford
This means that each RnGnBnxn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
The associated UNORM and SRGB formats already exist.
Signed-off-by: Richard Sandiford
Reviewed-by: Brian Paul
Signed-off-by: Dave Airlie
Hi,
I've taken Richard's previous patchset and rebased them on top of
current mesa formats code, I pushed some of Richard's other patches
already but these needs some changes, so I thought I'd repost them
in case anyone wanted to take a look.
Dave.
___
From: Richard Sandiford
Luminance is the least-significant byte of the uint16, rather than the
lowest byte in memory. Other parts of mesa already handle this correctly
for big-endian, and swrast already handles other MESA_FORMAT_x8y8 formats
correctly. This case was just an odd-one-out.
Signed
From: Richard Sandiford
MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of
the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw.
PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory.
This patch fixes up the mesa<->gallium mapping accordingly.
Signe
From: Richard Sandiford
...i.e. formats in which the alpha or green channel is first in memory.
This means that each LnAn and RnGn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
Signed-off-by: Richard Sandiford
Reviewed-by: Brian Paul
Si
From: Richard Sandiford
This means that each SRGB format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
Signed-off-by: Richard Sandiford
Signed-off-by: Dave Airlie
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/f
From: Dave Airlie
This was being shared using a ../../ get out of gallium into
mesa, and I swore when I did it I'd fix things when we got a util
dir, we did, so I have.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/util/u_format_latc.c | 72 ++---
src/gallium/auxiliary/util/u_format_rg
Am 15.09.2014 21:28, schrieb Roland Scheidegger:
> Am 15.09.2014 21:00, schrieb Ilia Mirkin:
>> On Mon, Sep 15, 2014 at 2:51 PM, wrote:
>>> From: Roland Scheidegger
>>>
>>> sample opcodes don't have valid texture target information (and I don't
>>> think
>>> this should be changed), however it
From: Roland Scheidegger
sample opcodes don't have valid texture target information (and I don't think
this should be changed), however it would be nice if we had that information
ready elsewhere, so stuff that information into the tgsi info when analyzing
a shader.
v2: Ilja Mirkin spotted some
https://bugs.freedesktop.org/show_bug.cgi?id=83631
--- Comment #5 from Orion Poplawski ---
So, make the test:
$ cat gltest.c
#define GL_GLEXT_LEGACY
#include
int main(void)
{
GLintptr p;
return 0;
}
$ gcc gltest.c
In file included from /usr/include/GL/glx.h:333:0,
from g
Am 15.09.2014 08:31, schrieb Kenneth Graunke:
> Fredrik's implementation of ARB_vertex_attrib_binding introduced new
> gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and
> converted Mesa's older gl_client_array to be derived state. Ultimately,
> we'd like to drop gl_client_array a
The blitter will start at a pixel's natural alignment. For PBOs, if the
provided offset if not aligned, bits will get dropped.
This change adds offset alignment check for src and dst, kicking back if
the requirements are not met.
The change is based on following verbiage from BSPEC:
Color pixel
This patch is
Reviewed-by: Ian Romanick
On 09/14/2014 10:07 AM, mathias.froehl...@gmx.net wrote:
> From: Mathias Froehlich
>
> Factor out some functions that will get additional callers
> with the implementation of NV_depth_buffer_float.
>
> Signed-off-by: Mathias Froehlich
> ---
> src/mesa
On 09/15/2014 10:41 AM, Roland Scheidegger wrote:
> Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
>> From: Mathias Fröhlich
>>
>> Will be used in the implementation of NV_depth_buffer_float.
>>
>> Signed-off-by: Mathias Froehlich > ---
>> src/mesa/main/glformats.c | 18 +
Am 15.09.2014 22:48, schrieb Dave Airlie:
>>
>> I never really looked at the big endian stuff so I have no idea if this
>> is right. I thought though the channel shift thing now should work
>> without endianness awareness if you fetch one 32bit number and then
>> break it up into parts with shifts
https://bugs.freedesktop.org/show_bug.cgi?id=70920
Erik Faye-Lund changed:
What|Removed |Added
Attachment #106343|0 |1
is obsolete|
On Mon, Sep 15, 2014 at 4:48 PM, Dave Airlie wrote:
>>
>> I never really looked at the big endian stuff so I have no idea if this
>> is right. I thought though the channel shift thing now should work
>> without endianness awareness if you fetch one 32bit number and then
>> break it up into parts w
>
> I never really looked at the big endian stuff so I have no idea if this
> is right. I thought though the channel shift thing now should work
> without endianness awareness if you fetch one 32bit number and then
> break it up into parts with shifts due to the channel information being
> adjusted
https://bugs.freedesktop.org/show_bug.cgi?id=70920
--- Comment #5 from Erik Faye-Lund ---
Created attachment 106343
--> https://bugs.freedesktop.org/attachment.cgi?id=106343&action=edit
error-checking in glsl-compiler
What's going on here, seems to be that we're running out of memory while
lin
Kenneth Graunke writes:
> Fredrik's implementation of ARB_vertex_attrib_binding introduced new
> gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and
> converted Mesa's older gl_client_array to be derived state. Ultimately,
> we'd like to drop gl_client_array and use those structu
Am 15.09.2014 21:00, schrieb Ilia Mirkin:
> On Mon, Sep 15, 2014 at 2:51 PM, wrote:
>> From: Roland Scheidegger
>>
>> sample opcodes don't have valid texture target information (and I don't think
>> this should be changed), however it would be nice if we had that information
>> ready elsewhere,
On Mon, Sep 15, 2014 at 2:51 PM, wrote:
> From: Roland Scheidegger
>
> sample opcodes don't have valid texture target information (and I don't think
> this should be changed), however it would be nice if we had that information
> ready elsewhere, so stuff that information into the tgsi info when
From: Roland Scheidegger
sample opcodes don't have valid texture target information (and I don't think
this should be changed), however it would be nice if we had that information
ready elsewhere, so stuff that information into the tgsi info when analyzing
a shader.
---
src/gallium/auxiliary/gal
From: Rafael Ávila de Espíndola
It looks like it was possible to attach it to both for a long time, however
since llvm r217548 attaching it to just the pass manager is no longer
sufficient and causes bugs (see http://llvm.org/bugs/show_bug.cgi?id=20903).
Tested-by: Vinson Lee
---
src/gallium/a
From: Roland Scheidegger
sample opcodes are a little oddly represented in the opcode_info, since
they don't count as texture instructions - they don't have valid target
information, but they may have offsets (unlike "ordinary" texture
instructions, the texture token may be optional for them).
So
From: Roland Scheidegger
sample opcodes don't encode a texture target, it would thus always
print UNKNOWN, which is not helpful (and wouldn't parse when giving
back the shader text to tgsi).
---
src/gallium/auxiliary/tgsi/tgsi_dump.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
From: Roland Scheidegger
This is just a very limited version, in particular sampler and sampler view
index must be the same. It cannot handle any modifiers neither.
Works much the same as soa version otherwise, to figure out the target we
need to store the sampler view dcls.
While here, also hand
Am 15.09.2014 19:04, schrieb Mathias Fröhlich:
>
> Hi again,
>
> On Monday, September 15, 2014 18:11:51 Roland Scheidegger wrote:
>> btw I'm not entirely sure everything is really correct with llvmpipe wrt
>> that extension (the rasterization stuff, gallium isn't involved in the
>> texture conver
Am 15.09.2014 18:28, schrieb Mathias Fröhlich:
>
> Hi Roland,
>
> On Monday, September 15, 2014 16:57:49 Roland Scheidegger wrote:
>> Hmm actually that wasn't right, it does make a difference if the nv or
>> core format enums are used, at least for texture specification (nv won't
>> clamp, wherea
Hi again,
On Monday, September 15, 2014 18:11:51 Roland Scheidegger wrote:
> btw I'm not entirely sure everything is really correct with llvmpipe wrt
> that extension (the rasterization stuff, gallium isn't involved in the
> texture conversion). There's some very annoying differences how things
>
https://bugs.freedesktop.org/show_bug.cgi?id=71199
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
Blocks|
https://bugs.freedesktop.org/show_bug.cgi?id=79706
Vinson Lee changed:
What|Removed |Added
Depends on||71199
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=79706
Vinson Lee changed:
What|Removed |Added
Depends on||70359
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=70359
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
Blocks|
Hi,
On Monday, September 15, 2014 18:11:51 Roland Scheidegger wrote:
> btw I'm not entirely sure everything is really correct with llvmpipe wrt
> that extension (the rasterization stuff, gallium isn't involved in the
> texture conversion). There's some very annoying differences how things
> work
Hi Roland,
On Monday, September 15, 2014 16:57:49 Roland Scheidegger wrote:
> Hmm actually that wasn't right, it does make a difference if the nv or
> core format enums are used, at least for texture specification (nv won't
> clamp, whereas core will) and probably for rasterization too, what a
>
Am 15.09.2014 16:57, schrieb Roland Scheidegger:
> Am 15.09.2014 16:41, schrieb Roland Scheidegger:
>> Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
>>> From: Mathias Fröhlich
>>>
>>> Will be used in the implementation of NV_depth_buffer_float.
>>>
>>> Signed-off-by: Mathias Froehlich >>
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
> From: Mathias Fröhlich
>
> This is mostly support for the unclamped versions of
> glDepthRangedNV, glClearDepthdNV and glDepthBoundsdNV.
> Note that OpenGL 4.2 introduced that the traditonal
> glDepthRange functions may no longer clamp to
https://bugs.freedesktop.org/show_bug.cgi?id=83631
--- Comment #4 from Orion Poplawski ---
It seems that in GL/glx.h, GL/glext.h is only included when
GL_GLEXT_LEGACY is not defined (line 2049).
Unfortunatly, GL_GLEXT_LEGACY is defined in Rendering/OpenGL/vtkOpenGL.h
(line 22) and
vtkOpenGL.h i
Am 15.09.2014 16:41, schrieb Roland Scheidegger:
> Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
>> From: Mathias Fröhlich
>>
>> Will be used in the implementation of NV_depth_buffer_float.
>>
>> Signed-off-by: Mathias Froehlich > ---
>> src/mesa/main/glformats.c | 18 ++
On Fri, 2014-09-12 at 18:20 -0400, Nick Sarnie wrote:
> Trivial patch to create the pipe loader for ilo. All the code was
> already there.
>
> Signed-off-by: Nick Sarnie
> ---
> src/gallium/targets/pipe-loader/Makefile.am | 14 ++
> src/gallium/targets/pipe-loader/pipe_i965.c | 26
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
> From: Mathias Fröhlich
>
> Will be used in the implementation of NV_depth_buffer_float.
>
> Signed-off-by: Mathias Froehlich ---
> src/mesa/main/glformats.c | 18 ++
> src/mesa/main/glformats.h | 3 +++
> 2 files change
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
> From: Mathias Fröhlich
>
> In preparation of NV_depth_buffer_float. Let the
> driver decide if it could support writing depth values
> beyond the [0, 1] range.
>
> Signed-off-by: Mathias Froehlich ---
> src/gallium/docs/source/screen.rs
Am 15.09.2014 08:55, schrieb Dave Airlie:
> From: Dave Airlie
>
> The triangle_32_ rast functions never made it into the debug output,
> confused me for a few seconds.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/llvmpipe/lp_rast_debug.c | 11 +++
> 1 file changed, 11 ins
Am 15.09.2014 12:22, schrieb Dave Airlie:
>> We had a bug report from some screensavers in xscreensaver package
>> not working on ppc64be, I took a day out to cause myself undue pain.
>>
>> I tracked it down to the depth buffer not being read correctly,
>> I've no idea if this is the proper fix for
> We had a bug report from some screensavers in xscreensaver package
> not working on ppc64be, I took a day out to cause myself undue pain.
>
> I tracked it down to the depth buffer not being read correctly,
> I've no idea if this is the proper fix for it, I need to run
> some more piglit on it. (m
From: Dave Airlie
We had a bug report from some screensavers in xscreensaver package
not working on ppc64be, I took a day out to cause myself undue pain.
I tracked it down to the depth buffer not being read correctly,
I've no idea if this is the proper fix for it, I need to run
some more piglit
54 matches
Mail list logo
