Am 12.12.2013 23:47, schrieb Aaron Watry:
Prevents a potential memory leak found when tracking down something else.
Patch is : Reviewed-by: Christian König
---
src/gallium/state_trackers/vdpau/device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/vdpau/de
Kenneth Graunke writes:
> On 11/26/2013 12:02 AM, Francisco Jerez wrote:
> [snip]
>> + add_image_function("imageLoad",
>> + image_builtin_builder(*this)
>> + .emit_stub("__intrinsic_image_load")
>> + .has_return()
>> +
This is worse for SW renderers...
Jose
- Original Message -
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_cb_clear.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_clear.c
> b/src/mesa/state_tracker/st_cb_cl
Also move a comment that was in the wrong place.
---
src/gallium/drivers/radeonsi/si_state.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index d99cfe8..ee2372f 100644
--- a/src/gallium/
It will only be worse for combined Z-stencil buffers if Z and
stencil are interleaved, and if SW rasterizers don't support any kind
of fast clear.
Marek
On Fri, Dec 13, 2013 at 3:21 PM, Jose Fonseca wrote:
> This is worse for SW renderers...
>
> Jose
>
> - Original Message -
>> From: Mar
What you mean by "fast clear"?
llvmpipe depth-stencil buffers are interleaved, and AFAICT partial clears will
be done with quads. In other words, this will make llvmpipe slower.
In truth, this will all drivers with interleaved z/s bufferss slower. That is,
this is optimizing for some drivers
HiS might be useful for anything that uses id Tech 4, like Doom 3,
ETQW, etc. I'm not sure about later chips, but R300-R500 has to
disable HiZ entirely if certain stencil operations are used.
Marek
On Fri, Dec 13, 2013 at 4:58 PM, Andreas Hartmetz wrote:
> Also move a comment that was in the wro
Hi Chris,
How goes arb_texture_view?
I'd like to see what you have. Please let me know if I can help.
Thanks,
Courtney
On Mon, Nov 25, 2013 at 1:42 PM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:
> I've added a viewport_array-rc2 branch to my github repository with
> updates from t
On Thu, Dec 12, 2013 at 01:26:36AM -0800, Kenneth Graunke wrote:
> The PIPE_CONTROL packet actually has 5 DWords on Gen6+:
> 1. Header
> 2. Flags
> 3. Address
> 4. Immediate Data: Lower DWord
> 5. Immediate Data: Upper DWord
>
> We just never emitted the last one. While it appears to work, it's
>
On Thu, Dec 12, 2013 at 01:26:37AM -0800, Kenneth Graunke wrote:
> The kernel doesn't even set up the aliasing PPGTT on Sandybridge, so any
> writes marked as PPGTT will likely just get dropped on the floor.
Ermh, aliasing ppgtt is enabled on snb. But the CS write stuff is broken
and will always l
On Thu, Dec 12, 2013 at 01:26:38AM -0800, Kenneth Graunke wrote:
> I believe that PIPE_CONTROL uses the length field to decide whether to
> do 32-bit or 64-bit writes. A length of 4 would do a 32-bit write,
> while a length of 5 would do a 64-bit write. (I haven't verified this,
> though.)
>
> F
On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
> Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
> and the second DWord is the high 16 bits.
>
> Since individual buffers shouldn't be larger than 4GB in size, any
> offsets into those buffers (buffer->offset +
On 12/13/2013 09:28 AM, Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
>> Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
>> and the second DWord is the high 16 bits.
>>
>> Since individual buffers shouldn't be larger than 4GB in size,
From: Roland Scheidegger
Didn't really work as well as hoped (in particular it was not generally
more accurate), will solve this differently.
---
src/gallium/drivers/llvmpipe/lp_state_setup.c | 70 ++---
1 file changed, 4 insertions(+), 66 deletions(-)
diff --git a/src/gal
- Original Message -
> From: Roland Scheidegger
>
> Didn't really work as well as hoped (in particular it was not generally
> more accurate), will solve this differently.
> ---
> src/gallium/drivers/llvmpipe/lp_state_setup.c | 70
> ++---
> 1 file changed, 4 inse
I agree that this seems to be pretty bad if you have interleaved
depth/stencil buffers (and no way to fast-clear them independently),
though I wonder which apps actually hit this? It looks to me like the
conditions you'd hit quad clear with one of depth/stencil but normal
clear with the other are f
I got it sort of running on Jenkins, on the master branch.
I can't have it build all the way through, because I'm a bit worried it'll
try to overwrite my currently installed version of Mesa on my system.
But it does tell me :
Run 'make' to build Mesa
Finished: SUCCESS
I'm guessing tests have t
I'll add a cap then.
The fast clear is a technique that doesn't actually clear memory.
Instead, it postpones clearing until later time in hope that the
cleared area will be overdrawn anyway and no clearing will have to be
done. The idea is to have a clear/non-cleared 1-bit flag per tile.
Instead o
This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full miptrees where were found to be common activities
in the Smokin' Guns game. The issue was found while profiling the app
but that part is not
MESA_FORMAT_XRGB is equivalent to MESA_FORMAT_ARGB in terms
of storage on the device, so okay to use this optimized copy routine.
This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full m
Support all levels of a supported texture format.
Using 1024x1024, RGBA source, mipmap
internal-format Before (MB/sec) mipmap (MB/sec)
GL_RGBA 627.15 615.90
GL_RGB 456.35 611.53
512x512
GL_RGBA 597.00 619.95
GL_RGB 440.62
https://bugs.freedesktop.org/show_bug.cgi?id=72582
--- Comment #1 from Ian Romanick ---
I haven't look at this test (and for some reason it doesn't show up in my
piglit runs), but I suspect this is the same issue at the copyteximage test.
copyteximage tries to use array textures with fixed-funct
From: Roland Scheidegger
The argument is a i8 pointer not a i32 pointer (even though the value actually
stored/loaded IS i32). Older llvm versions didn't care but 3.2 and newer do
leading to crashes.
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c |9 +++--
1 file changed, 7 insertions(+
https://bugs.freedesktop.org/show_bug.cgi?id=72582
Ian Romanick changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|Other
Just use the gl_texture_object::_IsInteger field instead of
computing it from scratch.
---
src/mesa/state_tracker/st_atom_sampler.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_sampler.c
b/src/mesa/state_tracker/st_atom_sampler.c
ind
---
src/mesa/state_tracker/st_format.c |6 +++---
src/mesa/state_tracker/st_format.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index ec25523..6acf983 100644
--- a/src/mesa/state_tracker/st_
---
src/mesa/state_tracker/st_atom_sampler.c |6 +++---
src/mesa/state_tracker/st_texture.h |6 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_sampler.c
b/src/mesa/state_tracker/st_atom_sampler.c
index 989e42c..447788c 100644
---
The GL_ARB_shadow spec says the shadow compare mode should have no
effect when sampling a color texture. As it was, it was up to
drivers to check for that (softpipe, llvmpipe, svga and probably
the rest don't do that). Note: it looks like DX10 allows shadow
compare with some non-depth formats, so
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #10 from Ian Romanick ---
OpenGL ES 3.0 is intended to be almost completely backwards compatible with
OpenGL ES 2.0. The only known incompatibilities are cubemap filtering (ES3
requires seamless filtering, but ES2 requires non-seamle
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #11 from org.freedesk...@io7m.com ---
Yes, those are the conclusions I came to as well.
The only issue here, then, is the minor irritation of the ES3 context not
setting
EGL_OPENGL_ES3_BIT_KHR. I think that's a conformance issue but I
Looks good. Thanks Roland!
- Original Message -
> From: Roland Scheidegger
>
> The argument is a i8 pointer not a i32 pointer (even though the value
> actually
> stored/loaded IS i32). Older llvm versions didn't care but 3.2 and newer do
> leading to crashes.
> ---
> src/gallium/auxilia
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #12 from Jordan Justen ---
(In reply to comment #11)
> The only issue here, then, is the minor irritation of
> the ES3 context not setting EGL_OPENGL_ES3_BIT_KHR.
> I think that's a conformance issue but I doubt anyone's
> going to no
Am 13.12.2013 21:32, schrieb Brian Paul:
> The GL_ARB_shadow spec says the shadow compare mode should have no
> effect when sampling a color texture. As it was, it was up to
> drivers to check for that (softpipe, llvmpipe, svga and probably
> the rest don't do that). Note: it looks like DX10 allo
I tried to tackle this issue:
>> There is still the issue regarding the following:
>> According to the spec, it should be possible to clear some part of a
>> buffer, even if a different, non-overlapping part is mapped, this is
>> currently not possible. It was suggested to implement ClearBufferSubD
On 12/12/2013 01:56 PM, Brian Paul wrote:
> ---
> include/GL/glext.h | 68
> ++--
> 1 file changed, 61 insertions(+), 7 deletions(-)
>
> diff --git a/include/GL/glext.h b/include/GL/glext.h
> index fea9e1f..7d6033e 100644
> --- a/include/GL/glext
On Fri, Dec 13, 2013 at 10:04:53AM -0800, Kenneth Graunke wrote:
> On 12/13/2013 09:28 AM, Daniel Vetter wrote:
> > On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
> >> Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
> >> and the second DWord is the high 16 bi
On 11/21/2013 08:12 PM, Keith Packard wrote:
> The __DRIimage createImageFromFds function takes a fourcc code, but there was
> no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
> that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
> __DRI_IMAGE_FOURCC
On 11/25/2013 09:35 PM, Keith Packard wrote:
> Move the depth field up with width and height.
>
> Remove unused previous_time and frames fields.
>
> Signed-off-by: Keith Packard
> ---
> src/glx/dri3_priv.h | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/src/glx/dr
---
src/mesa/drivers/dri/swrast/swrast.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/swrast/swrast.c
b/src/mesa/drivers/dri/swrast/swrast.c
index cfa9316..79a2740 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/sw
---
src/gallium/state_trackers/dri/sw/drisw.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/dri/sw/drisw.c
b/src/gallium/state_trackers/dri/sw/drisw.c
index 64a64af..6f50b05 100644
--- a/src/gallium/state_trackers/dri/sw/drisw.c
+++ b/src/galliu
On 12/13/2013 03:17 PM, Pi Tabred wrote:
I tried to tackle this issue:
There is still the issue regarding the following:
According to the spec, it should be possible to clear some part of a
buffer, even if a different, non-overlapping part is mapped, this is
currently not possible. It was sugges
Kenneth Graunke writes:
> I see that Eric reviewed it, and that it has not landed. Are there any
> objections to merging it?
They're on top of a series of DRI3/Present patches, not all of which
have seen review. I was hoping the rest of that series would get
reviewed so that I could merge it al
These are the same address, but different types and driContextSetFlags wants
a gl_context pointer.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/swrast/swrast.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/swrast/swrast.c
b/src/mesa/drivers/dr
These are duplicates from gl.h; I'm not sure which file they belong in, but
you don't get to have them in both places.
Signed-off-by: Keith Packard
---
include/GL/glext.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 7d6033e..b432d2e 100644
--
It is the maximum number of back buffers, but the name is confusing and is
easily read as the maximum back buffer index. Chage to DRI3_NUM_BACK to make
the intended usage a bit clearer.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 4 ++--
src/glx/dri3_priv.h | 10 +-
2 files c
This series has a bunch of DRI3 cleanups and fixes followed by a few patches
that finish up DRI3 support in gallium.
The first two patches have nothing to do with DRI3, just some warning fixes:
[PATCH 01/18] Remove glBlendColor and glBlendEquations decls from
[PATCH 02/18] dri/swrast: Passing d
Tracking the full 64-bit SBC values makes it clearer how those values are
being used, and simplifies the wait_msc code. The only trick is in
re-constructing the full 64-bit value from Present's 32-bit serial number that
we use to pass the SBC value from request to event.
Signed-off-by: Keith Packa
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard
---
configure.ac | 8 -
src/glx/dri3_common.c | 85 ++-
2 files changed, 50 in
Now that we're tracking SBC values correctly, and the X server has the ability
to send the GLX swap events from a PresentPixmap request, enable this extension.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git
XCB doesn't flush the output buffer automatically, so we have to call
xcb_flush ourselves before waiting.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index c26d6e5..7982f6b 100644
--- a/src/glx/
Move the depth field up with width and height.
Remove unused previous_time and frames fields.
Signed-off-by: Keith Packard
Reviewed-by: Kenneth Graunke
---
src/glx/dri3_priv.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
ind
Just copying code from the dri2 path to set up the fast color clear state.
This also removes a couple of bogus intel_region_reference calls.
Signed-off-by: Keith Packard
Reviewed-by: Eric Anholt
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
1 file changed, 7 insertions(+),
Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC
had been completed, which means to wait until the PresentCompleteNotify event
for that SBC had been received.
This replaces the simple sleep(1) loop (which was bogus) with a loop that just
checks to see if we've seen th
The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
__DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
__IMA
From: Ben Skeggs
Signed-off-by: Ben Skeggs
Signed-off-by: Keith Packard
---
src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.
From: Ben Skeggs
Signed-off-by: Ben Skeggs
Signed-off-by: Keith Packard
---
src/gallium/state_trackers/dri/drm/dri2.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri
Upper levels of the stack use base.stamp to tell when a drawable needs to be
revalidated, but the dri state tracker was using dPriv->lastStamp. Those two,
along with dri2.stamp, all get simultaneously incremented when a dri2
invalidate event was delivered, and so end up containing precisely the sam
libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
works when the fence is a linux futex. However, version 1.1
changes the exported datatype to 'struct xshmfence *'
Require libxshmfence version 1.1 and switch the API around.
Signed-off-by: Keith Packard
---
configure.ac
Always nice to clean up after ourselves.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 17 -
src/glx/dri3_priv.h | 5 -
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 1834c6d..4c0dc29 100644
--- a/src/gl
The buffer-object is the persistent thing passed through the loader, so when
updating an image buffer, check to see if it is already bound to the provided
bo. The region, on the other hand, is allocated separately for the miptree,
and so will never be the same as that passed back from the loader.
Provide the hook to pull textures out of __DRIimage structures and use them as
renderbuffers.
Signed-off-by: Keith Packard
---
src/gallium/state_trackers/dri/drm/dri2.c | 238 +-
1 file changed, 230 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_tracker
On 12/13/2013 05:25 PM, Keith Packard wrote:
> These are duplicates from gl.h; I'm not sure which file they belong in, but
> you don't get to have them in both places.
>
> Signed-off-by: Keith Packard
> ---
> include/GL/glext.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/G
On 11/18/2013 12:58 PM, Emil Velikov wrote:
> On 18/11/13 01:08, Keith Packard wrote:
>> libudev doesn't have a stable API/ABI, and if the application wants to use
>> one
>> version, we'd best not load another into libGL.
>>
>> Signed-off-by: Keith Packard
>> ---
>>
> Hi Keith,
>
> Did you had t
On 12/13/2013 05:25 PM, Keith Packard wrote:
> libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
> works when the fence is a linux futex. However, version 1.1
> changes the exported datatype to 'struct xshmfence *'
>
> Require libxshmfence version 1.1 and switch the API around
None of the other 3-component 16bpc formats are directly supported, so
they get promoted to XRGB equivalents. *Not* promoting RGB16F the same
way makes texture views much more fiddly -- we don't want to have to do
crazy copying behind the scenes.
(with my other master + my experimental ARB_texture
Kenneth Graunke writes:
> NAK. These headers come directly from Khronos; we need to somehow get
> this fixed upstream and take their version.
Until they're fixed upstream, we should fix them when incorporating them
into the repository. Having broken headers in our code just because
they're brok
Kenneth Graunke writes:
> Would be great to line these comments up.
Fixed.
> Patches 2 and 4-6 are:
> Reviewed-by: Kenneth Graunke
Review marked. Thanks much!
--
keith.pack...@intel.com
pgpkJlR4qfmew.pgp
Description: PGP signature
___
mesa-dev m
67 matches
Mail list logo
