Hi,
as requested by Paul, I've converted the patch which provides anisotropic
filtering for swrast to softpipe. The rendering results of both version are
almost identical and are much better compared to typical HW rendering, e.g.
NVIDIA which produces a lot more aliasing.
Andreas
Andreas Faen
Hi,
as requested by Paul, I've converted the patch which provides anisotropic
filtering for swrast to softpipe. The rendering results of both version are
almost identical and are much better compared to typical HW rendering, e.g.
NVIDIA which produces a lot more aliasing.
Andreas
Andreas Faen
Hi,
as requested by Paul, I've converted the patch which provides anisotropic
filtering for swrast to softpipe. The rendering results of both version are
almost identical and are much better compared to typical HW rendering, e.g.
NVIDIA which produces a lot more aliasing.
Andreas
Andreas Faen
Hi,
as requested by Paul, I've converted the patch which provides anisotropic
filtering for swrast to softpipe. The rendering results of both version are
almost identical and are much better compared to typical HW rendering, e.g.
NVIDIA which produces a lot more aliasing.
Andreas
Andreas Faen
Reference implementation which produces high quality renderings.
Based on Higher Quality Elliptical Weighted Avarage Filter (EWA).
---
src/gallium/drivers/softpipe/sp_screen.c |4 +-
src/gallium/drivers/softpipe/sp_tex_sample.c | 331 ++
2 files changed, 333 insert
Hi!
While trying to improve the vmwgfx X driver to better cope with OpenGL
compositors, I noticed that compiz never calls glxWaitX() to make sure
the pixmaps that it textures from are updated.
Since we migrate X rendered data to the dri2 drawables only on demand,
we miss a lot of data.
Goo
Andreas,
This looks very interesting. Ultimately llvmpipe would want to have aniso as
well, but performance would be much more important there. Do you have a
feeling for what shortcuts the hardware implementations are taking?
Keith
- Original Message -
From: "Andreas Faenger"
To: me
On Mon, Jun 6, 2011 at 1:13 AM, Andreas Faenger wrote:
> Reference implementation which produces high quality renderings.
> Based on Higher Quality Elliptical Weighted Avarage Filter (EWA).
Thanks. I'm just going to run some tests to check for regressions
before committing/pushing.
-Brian
_
On 6/6/11 2:09 AM, "Thomas Hellstrom" wrote:
> Hi!
>
> While trying to improve the vmwgfx X driver to better cope with OpenGL
> compositors, I noticed that compiz never calls glxWaitX() to make sure
> the pixmaps that it textures from are updated.
>
> Since we migrate X rendered data to the dri
Am 05.06.2011 03:55, schrieb Benjamin Bellec:
> Le 05/06/2011 03:05, Matt Turner a écrit :
>> On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec wrote:
>>> Le 03/06/2011 06:09, Matt Turner a écrit :
Also, if you want to check if the value is already a power-of-two,
instead of a case stateme
We need pci id to driver-name mapping for drm and
wayland platforms in egl_dri2 and egl_gallium.
egl_dri2 holds a own list, which is redundant with the information
thats already stored in the drivers.
egl_gallium uses the kernel name, which is not always the
actual 3d driver name (e.g. radeon -> r
---
src/mesa/drivers/dri/intel/i915_pci_ids.h | 19 +++
src/mesa/drivers/dri/intel/i965_pci_ids.h | 27 +++
2 files changed, 46 insertions(+), 0 deletions(-)
create mode 100644 src/mesa/drivers/dri/intel/i915_pci_ids.h
create mode 100644 src/mesa/drive
---
src/mesa/drivers/dri/radeon/r200_pci_ids.h | 22 +++
src/mesa/drivers/dri/radeon/r300_pci_ids.h | 218 +
src/mesa/drivers/dri/radeon/r600_pci_ids.h | 261 ++
src/mesa/drivers/dri/radeon/radeon_pci_ids.h | 23 +++
4 files changed, 524 inse
Make use of this in drm and wayland st/egl backends.
---
src/gallium/state_trackers/egl/drm/native_drm.c| 33 +
.../state_trackers/egl/wayland/native_drm.c| 40 +--
src/gallium/targets/egl/egl.c | 80 +++-
src/gallium/targets/e
---
src/mesa/drivers/dri/radeon/radeon_chipset.h | 499 +-
1 files changed, 8 insertions(+), 491 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_chipset.h
b/src/mesa/drivers/dri/radeon/radeon_chipset.h
index bd23662..0e51325 100644
--- a/src/mesa/drivers/dri
---
src/gallium/winsys/r600/drm/Makefile |1 +
src/gallium/winsys/r600/drm/radeon_pciid.c | 486 +---
2 files changed, 6 insertions(+), 481 deletions(-)
diff --git a/src/gallium/winsys/r600/drm/Makefile
b/src/gallium/winsys/r600/drm/Makefile
index 7310734..45fd
---
src/egl/drivers/dri2/Makefile |2 +-
src/egl/drivers/dri2/common.c | 110 ++
src/egl/drivers/dri2/egl_dri2.h |2 +
src/egl/drivers/dri2/pci_ids.h | 62
src/egl/drivers/dri2/platform_drm.c | 663 +--
5 files changed, 176
On Mon, Jun 6, 2011 at 11:34 AM, Roland Scheidegger wrote:
> Am 05.06.2011 03:55, schrieb Benjamin Bellec:
>> Le 05/06/2011 03:05, Matt Turner a écrit :
>>> On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec wrote:
Le 03/06/2011 06:09, Matt Turner a écrit :
> Also, if you want to check if t
On Mon, Jun 6, 2011 at 11:49 AM, Benjamin Franzke
wrote:
> We need pci id to driver-name mapping for drm and
> wayland platforms in egl_dri2 and egl_gallium.
>
> egl_dri2 holds a own list, which is redundant with the information
> thats already stored in the drivers.
> egl_gallium uses the kernel
src/glx/apple should land in MesaLib. What magic needs to be done to make sure
it lands up there? This was a problem with 7.8.x, and I just solved it by
putting out my own MesaLibApple-7.8.2. 7.9.x and 7.10.x didn't build on
darwin, so it wasn't really a concern.
I've gone through and fixed
On Mon, Jun 6, 2011 at 10:19 AM, Jeremy Huddleston
wrote:
> src/glx/apple should land in MesaLib. What magic needs to be done to make
> sure it lands up there? This was a problem with 7.8.x, and I just solved it
> by putting out my own MesaLibApple-7.8.2. 7.9.x and 7.10.x didn't build on
> d
Am 05.06.2011 06:31, schrieb Younes Manton:
> 2011/6/4 Jose Fonseca :
>> At very least there are ovious things that need to be fixed:
>>
>> - get_param / is_format_supported should not be duplicated from screen.
>
> This is also deliberate. Params and surface formats may depend on the
> codec/prof
Well radeon_drm_public.h declares radeon_drm_winsys_create(),
but yea is_r3xx should be replaced.
Patch attached.
2011/6/6 Alex Deucher :
> On Mon, Jun 6, 2011 at 11:49 AM, Benjamin Franzke
> wrote:
>> We need pci id to driver-name mapping for drm and
>> wayland platforms in egl_dri2 and egl_gall
Could you put the PCI IDs in a better place than src/mesa? How about
src/common? Or something like that.
Marek
On Mon, Jun 6, 2011 at 5:49 PM, Benjamin Franzke
wrote:
> We need pci id to driver-name mapping for drm and
> wayland platforms in egl_dri2 and egl_gallium.
>
> egl_dri2 holds a own lis
On Sun, 5 Jun 2011 13:04:24 -0700 (PDT), bugzilla-dae...@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=37959
>
>Summary: [regresssion] Errors starting sauerbraten with today's
> git master.
>Product: Mesa
>Version: gi
https://bugs.freedesktop.org/show_bug.cgi?id=37959
--- Comment #1 from Chad Versace 2011-06-06 10:26:55 PDT
---
On Sun, 5 Jun 2011 13:04:24 -0700 (PDT), bugzilla-dae...@freedesktop.org
wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=37959
>
>Summary: [regresssion] Errors star
On Mon, Jun 6, 2011 at 9:33 AM, Benjamin Franzke
wrote:
> Well radeon_drm_public.h declares radeon_drm_winsys_create(),
> but yea is_r3xx should be replaced.
> Patch attached.
I remember writing is_r3xx() way back when and feeling like it was a
horrible horrible hack. This is a great idea for a r
Le 06/06/2011 17:34, Roland Scheidegger a écrit :
> Am 05.06.2011 03:55, schrieb Benjamin Bellec:
>> Le 05/06/2011 03:05, Matt Turner a écrit :
>>> On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec wrote:
Le 03/06/2011 06:09, Matt Turner a écrit :
> Also, if you want to check if the value i
On Mon, Jun 6, 2011 at 12:33 PM, Benjamin Franzke
wrote:
> Well radeon_drm_public.h declares radeon_drm_winsys_create(),
> but yea is_r3xx should be replaced.
> Patch attached.
Looks good. Thanks. Overall the patch set looks fine to me. I agree
with Marek that it might be better to put the pci
2011/6/6 Alex Deucher :
> Looks good. Thanks. Overall the patch set looks fine to me. I agree
> with Marek that it might be better to put the pci ids together
> somewhere. For the series:
>
> Reviewed-by: Alex Deucher
Ok, moved the lists into include/pci_ids/, hope thats ok.
Updated patch se
On Mon, Jun 6, 2011 at 2:38 PM, Benjamin Franzke
wrote:
> 2011/6/6 Alex Deucher :
>> Looks good. Thanks. Overall the patch set looks fine to me. I agree
>> with Marek that it might be better to put the pci ids together
>> somewhere. For the series:
>>
>> Reviewed-by: Alex Deucher
>
> Ok, move
2011/6/6 Alex Deucher :
> Sorry, I just thought of one tricky situation. Only r600g supports
> CAYMAN asics, so r600c shouldn't have the CAYMAN pci ids. Maybe just
> split the CAYMAN ids out into a new header, cayman_pci_ids.h, and
> include both r600_pci_ids.h and cayman_pci_ids.h in r600g and o
---
src/gallium/drivers/i915/i915_fpc_translate.c | 94 +---
1 files changed, 82 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/i915/i915_fpc_translate.c
b/src/gallium/drivers/i915/i915_fpc_translate.c
index 695a396..51766cd 100644
--- a/src/gallium/drivers
https://bugs.freedesktop.org/show_bug.cgi?id=37840
Jesse Barnes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
2011/6/6 Stéphane Marchesin :
> ---
> src/gallium/drivers/i915/i915_fpc_translate.c | 94 +---
> 1 files changed, 82 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/drivers/i915/i915_fpc_translate.c
> b/src/gallium/drivers/i915/i915_fpc_translate.c
> index 695a39
On Mon, Jun 6, 2011 at 11:57 AM, Benjamin Bellec wrote:
> Le 06/06/2011 17:34, Roland Scheidegger a écrit :
>> Am 05.06.2011 03:55, schrieb Benjamin Bellec:
>>> Le 05/06/2011 03:05, Matt Turner a écrit :
On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec wrote:
> Le 03/06/2011 06:09, Matt T
On Mon, 6 Jun 2011 17:49:27 +0200, Benjamin Franzke
wrote:
> ---
> src/mesa/drivers/dri/intel/i915_pci_ids.h | 19 +++
> src/mesa/drivers/dri/intel/i965_pci_ids.h | 27 +++
> 2 files changed, 46 insertions(+), 0 deletions(-)
> create mode 100644 src/
On Mon, Jun 6, 2011 at 3:12 PM, Benjamin Franzke
wrote:
> 2011/6/6 Alex Deucher :
>> Sorry, I just thought of one tricky situation. Only r600g supports
>> CAYMAN asics, so r600c shouldn't have the CAYMAN pci ids. Maybe just
>> split the CAYMAN ids out into a new header, cayman_pci_ids.h, and
>>
2011/6/6 Eric Anholt :
> These 4 chipsets aren't part of the i915 driver.
>
> Other than that, thanks for taking this on! Looks like much more
> sanity, and we've talked about using something like the third argument
> to avoid some of the if trees we've got around.
>
Ok, thanks updated.
If there
https://bugs.freedesktop.org/show_bug.cgi?id=37862
--- Comment #6 from Pepi 2011-06-06 13:35:20 PDT ---
imake and LLVM was required to get it ready. And after ./autoconfig.sh it asked
me to use gmake instead of make. But are these drivers now 32b or 64b?
And where should I put them.and which
https://bugs.freedesktop.org/show_bug.cgi?id=37862
--- Comment #7 from Benjamin Bellec 2011-06-06 13:48:36
PDT ---
(In reply to comment #6)
> imake and LLVM was required to get it ready. And after ./autoconfig.sh it
> asked
> me to use gmake instead of make.
make is a shortcut for gmake (the Gn
On Sun, Jun 5, 2011 at 1:14 AM, Benjamin Bellec wrote:
> So here is a v2 patch with a builtin GCC optimization which is the
> fastest (thx Matt to point me to this solution).
>
>From patch:
+ return (1 << (32 - __builtin_clz(x - 1)));
I don't know if the use of gcc guarantees that int will
Am 06.06.2011 23:18, schrieb Tormod Volden:
> On Sun, Jun 5, 2011 at 1:14 AM, Benjamin Bellec wrote:
>> So here is a v2 patch with a builtin GCC optimization which is the
>> fastest (thx Matt to point me to this solution).
>>
>
> From patch:
> + return (1 << (32 - __builtin_clz(x - 1)));
>
On 06/04/2011 05:45 PM, Chad Versace wrote:
... which indicates if the X driver supports DRI2BufferHiz and
DRI2BufferStencil.
I'm placing this in its own commit due to the large comment block.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
On 06/04/2011 05:45 PM, Chad Versace wrote:
Add the fields below to intel_screen. The expression in parens is the
value to which intelInitScreen2() currently sets the field.
GLboolean hw_has_separate_stencil (true iff gen>= 7)
GLboolean hw_must_use_separate_stencil (true iff gen>=
On 06/04/2011 05:45 PM, Chad Versace wrote:
Remove functions intel_override_hiz() and
intel_override_separate_stencil(). They are now located in intel_screen.c.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
I'd probably squash this with
On 06/04/2011 05:45 PM, Chad Versace wrote:
When it is sensible to do so,
1) intelCreateBuffer() now attaches separate depth and stencil
buffers
to the framebuffer it creates.
2) intel_update_renderbuffers() requests for the framebuffer
a separate stencil buffer
https://bugs.freedesktop.org/show_bug.cgi?id=26073
Jeremy Huddleston changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30124
Bug 30124 depends on bug 29162, which changed state.
Bug 29162 Summary: mesa/darwin is severly broken
https://bugs.freedesktop.org/show_bug.cgi?id=29162
What|Old Value |New Value
-
Thanks for your great work on this, Chad.
You have my
Reviewed-by: Kenneth Graunke
There are a few (important) parts I glossed over, so I'd definitely like
to see review from the others, but overall the patches look solid. I'd
love to see this land soon so I can land Ivybridge stencil suppor
Since Gen7 doesn't support packed depth/stencil, the stencil buffer
can't possibly be relevant for determining the depth format.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_misc_state.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/mesa/driv
For ctx->Depth.Mask.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_misc_state.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 8d5fc70..0364b61 100644
I'm not actually sure how anything worked without this.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_misc_state.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/
Thanks to Chad's hard work implementing separate stencil and HiZ
support, this is entirely straightforward.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_misc_state.c | 61 ++
1 files changed, 42 insertions(+), 19 deletions(-)
diff --git a/src/mesa/
According to vol2a.07, it only applies from Cantiga to Sandybridge.
I found this in my ringbuffers while investigating various GPU hangs.
While it may not have been the cause, it seemed wise to remove it.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 16 +
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_wm_state.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index 993d5bd..6a64eb8 100644
--- a/src/mesa/drivers/
Fixes 17 piglit tests:
- glsl-vs-arrays-3
- glsl-vs-texturematrix-2
- glsl-vs-uniform-array-2
- arl
- nv-arl
- nv-init-zero-addr
- vp-address-01
- vp-arl-constant-array
- vp-arl-constant-array-huge
- vp-arl-constant-array-huge-offset
- vp-arl-constant-array-huge-offset-neg
- vp-arl-constant-array-h
Hi Chad,
Glad to see the Hiz patches.
Have you performance data for the Hiz patches, how much can this
improve?
Thanks
Zou Nanhai
-Original Message-
From: mesa-dev-bounces+nanhai.zou=intel@lists.freedesktop.org
[mailto:mesa-dev-bounces+nanhai.zou=intel@lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=37959
David Ronis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
I'm having trouble understanding why GLX_INDIRECT_RENDERING changes what is
built into glapi. I assumed that glapi was agnostic to the actual
implementation, so why does glapi care about GLX_INDIRECT_RENDERING?
I'm trying to build mesa with support for (only) indirect rendering on darwin.
lib
When GLX_INDIRECT_RENDERING is defined, some symbols are used in
libglapi.a but are not defined. Define them through the help of
glapitemp.h.
Signed-off-by: Jeremy Huddleston
Signed-off-by: Chia-I Wu
---
Please see my previous post for discussion. This patch fixes the build as
discussed in t
61 matches
Mail list logo
