Hi,
there's a new branch gallium-newclear which has some changes to clear
functionality in it. I think this could be expanded further in the
future to allow even more full-featured (GL) clears (as was briefly
discussed previously) but this addresses some concerns, in particular
needs of d3d10 and
> Kristian Høgsberg wrote:
>
>> Since an application needs to have an EGLDisplay before it can query
>> for extensions, the way to discover this extension is to just use
>> eglGetProcAddress().
>
> Eh... but eglGetProcAddress never returns NULL, does it? I know
> glXGetProcAddress never does.
egl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
> Since an application needs to have an EGLDisplay before it can query
> for extensions, the way to discover this extension is to just use
> eglGetProcAddress().
Eh... but eglGetProcAddress never returns NULL, does it? I kno
On Fri, 28 May 2010 13:35:46 -0400, Will Dyson wrote:
> The radeon driver will fail to allocate miptree space for a new level
> that is outside of BaseLevel..MaxLevel. Then it fails later, trying to
> migrate the level to a miptree. Set MaxLevel to dstLevel before
> allocating the level, and avoid
Will Dyson wrote:
On Fri, May 28, 2010 at 1:57 PM, Brian Paul wrote:
@@ -2400,6 +2400,9 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum
target,
break;
}
+ /* Set MaxLevel large enough to hold the new level when we
allocate it */
+ _mesa_TexParameteri(target, GL_TE
On Fri, May 28, 2010 at 1:57 PM, Brian Paul wrote:
>> @@ -2400,6 +2400,9 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum
>> target,
>> break;
>> }
>> + /* Set MaxLevel large enough to hold the new level when we
>> allocate it */
>> + _mesa_TexParameteri(target, GL_TE
2010/5/28 Jakob Bornecrantz :
> Some thoughs:
>
> Hmm I don't like adding new special entry points but I guess its much
> less magical then what we had before. Anyways thinking about it this
> does makes more sense. Please read the comments below, otherwise I'm
> fine with patch 1-3 of this series.
Will Dyson wrote:
The radeon driver will fail to allocate miptree space for a new level
that is outside of BaseLevel..MaxLevel. Then it fails later, trying to
migrate the level to a miptree. Set MaxLevel to dstLevel before
allocating the level, and avoid triggering the problem.
Signed-off-by: Wi
https://bugs.freedesktop.org/show_bug.cgi?id=28305
Summary: OSMesa built with autogen.sh cannot be used
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priori
This reverts commit a9ee95651131e27d5acf3d10909b5b7e5c8d3e92.
It was based on a failure to understand how the driver allocates
memory, and causes a regression with Celestia.
Signed-off-by: Will Dyson
---
src/mesa/drivers/dri/radeon/radeon_texture.c | 11 ---
1 files changed, 4 insertio
The radeon driver will fail to allocate miptree space for a new level
that is outside of BaseLevel..MaxLevel. Then it fails later, trying to
migrate the level to a miptree. Set MaxLevel to dstLevel before
allocating the level, and avoid triggering the problem.
Signed-off-by: Will Dyson
---
src/m
My change to image_matches_texture_obj() caused a regression when using
texImage with level > MaxLevel and pixels != null. Revert it, as the orignal
check was correct. Instead, change _mesa_meta_GenerateMipmap() to temporarily
raise MaxLevel when calling texImage. This allows radeon to correctly al
I'm not sure everything should be smacked into a single extension like
this. Stride and Handle are very DRM but the extension sounds a bit
generic.
I have some patches implementing similarly functionality and I will
post them tomorrow. They are conceptually similarly but the break all
of the separ
https://bugs.freedesktop.org/show_bug.cgi?id=28304
Summary: build fails on nouveau_stateobj.h
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
On Fri, May 28, 2010 at 8:46 AM, Chia-I Wu wrote:
> Hi all,
>
> I've got access to a Windows machine recently, and I've spent some time today
> to add GDI backend to st/egl. The code can be found at
>
> http://cgit.freedesktop.org/~olv/mesa/log/?h=egl-gdi
Cool stuff! Nice work.
>
> The command
Some thoughs:
Hmm I don't like adding new special entry points but I guess its much
less magical then what we had before. Anyways thinking about it this
does makes more sense. Please read the comments below, otherwise I'm
fine with patch 1-3 of this series.
Maybe we should not export eglGetDispla
https://bugs.freedesktop.org/show_bug.cgi?id=28280
Matthias Liertzer changed:
What|Removed |Added
Summary|Regression in mesa branch |Regression in mesa branches
https://bugs.freedesktop.org/show_bug.cgi?id=28280
--- Comment #2 from Matthias Liertzer 2010-05-28 08:27:31
PDT ---
The regression is also present in the mesa 7.8 branch and has only been fixed
in the master branch, see commit 26a9b7e4.
--
Configure bugmail: https://bugs.freedesktop.org/userp
Minor code comments below.
Kristian Høgsberg wrote:
---
include/EGL/eglext.h | 18 +
include/GL/internal/dri_interface.h| 13 +++
src/egl/drivers/dri2/egl_dri2.c| 110
src/egl/main/eglapi.c |
2010/5/28 Chia-I Wu :
...
> The right fix is to define a sensible "xorg/drm" platform which has different
> EGLNative{Display,Window,Pixmap}Type than the tentative ones as defined in
> eglplatform.h. The new platform should be able to fulfill all your
> requirements.
I think the "right fix" would
Hi all,
I've got access to a Windows machine recently, and I've spent some time today
to add GDI backend to st/egl. The code can be found at
http://cgit.freedesktop.org/~olv/mesa/log/?h=egl-gdi
The command options I use to build the DLLs are
$ scons statetrackers=egl drivers=softpipe
The
2010/5/28 Kristian Høgsberg :
> 2010/5/27 Brian Paul :
>> Kristian Høgsberg wrote:
>>>
>>> This patch introduces a new extension to allow different ways to
>>> create an EGLDisplay to exist within the same libEGL.so. The new
>>> extension, EGL_MESA_get_display, introduces a new entrypoint:
>>>
>>>
22 matches
Mail list logo
