On 05/03/2012 03:38 PM, Ian Romanick wrote:
To keep in the habit of doing regular releases, I'd like to propose
the following set of release dates. We had previously discussed doing
stable releases monthly and feature releases every six months. This
set of dates basically reflects that.
I should
On Thu, May 3, 2012 at 3:51 PM, Kristian Høgsberg wrote:
> On Thu, May 3, 2012 at 5:08 PM, Mandeep Baines
> wrote:
>> 2012/5/2 Kristian Høgsberg :
>>> This new gbm entry point allows writing data into a gbm bo. The bo has
>>> to be created with the GBM_BO_USE_WRITE flag, and it's only required
This patch removes ARB_framebuffer_object from the GLES1 and GLES2
extension lists in intel_extensions_es.c.
Fixes a crash in the Android browser on Ice Cream Sandwich.
The Android browser crashed because it did the following, which is legal
in GLES2 but not in ARB_framebuffer_object.
glGenFr
On 05/02/2012 06:32 PM, Chad Versace wrote:
> Mesa has problems in the way it implements glBindFramebuffer and
> glBindFramebufferEXT due to both being implemented by an overloaded
> _mesa_BindFramebufferEXT. This problem causes an Android app [1] to crash,
> and I want your opinion on how we shou
On Thu, May 3, 2012 at 5:08 PM, Mandeep Baines wrote:
> 2012/5/2 Kristian Høgsberg :
>> This new gbm entry point allows writing data into a gbm bo. The bo has
>> to be created with the GBM_BO_USE_WRITE flag, and it's only required to
>> work for GBM_BO_USE_CURSOR_64X64 bos.
>>
>> The gbm API is d
To keep in the habit of doing regular releases, I'd like to propose the
following set of release dates. We had previously discussed doing
stable releases monthly and feature releases every six months. This set
of dates basically reflects that.
I should be able to package up most of these, bu
2012/5/2 Kristian Høgsberg :
> This new gbm entry point allows writing data into a gbm bo. The bo has
> to be created with the GBM_BO_USE_WRITE flag, and it's only required to
> work for GBM_BO_USE_CURSOR_64X64 bos.
>
> The gbm API is designed to be the glue layer between EGL and KMS, but there
>
On 05/03/2012 11:49 AM, Chad Versace wrote:
On 05/03/2012 08:42 AM, Ian Romanick wrote:
On 05/02/2012 06:32 PM, Chad Versace wrote:
Quick Solution for the Intel drivers
A quick solution may be as simple as removing ARB_fbo from the Intel drivers'
GLES1/2
On 05/03/2012 08:42 AM, Ian Romanick wrote:
> On 05/02/2012 06:32 PM, Chad Versace wrote:
>> Quick Solution for the Intel drivers
>>
>>
>> A quick solution may be as simple as removing ARB_fbo from the Intel drivers'
>> GLES1/2 extension lists.
>>
>> Do you see
On 05/02/2012 02:48 PM, Paul Berry wrote:
When rendering to a miplevel other than 0 within a color, depth,
stencil, or HiZ buffer, we need to tell the GPU to render to an offset
within the buffer, so that the data is written into the correct
miplevel. We do this using a coarse offset (in pages),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2012 10:33 AM, Eric Anholt wrote:
> On Wed, 02 May 2012 18:32:01 -0700, Chad Versace
> wrote:
>> Solutions for core Mesa
>> ---
>>
>> As for fixing _mesa_BindFramebufferEXT, I have two ideas.
>>
>> 1. Enforce in _mesa_Bin
On 04/26/2012 06:54 AM, Paul Berry wrote:
> In i965 Gen6, Mesa has for a long time used the "depth coordinate
> offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to
> render to miplevels other than 0. Unfortunately, this doesn't work,
> because these offsets must be aligned to multip
On 05/02/2012 02:48 PM, Paul Berry wrote:
> When rendering to a miplevel other than 0 within a color, depth,
> stencil, or HiZ buffer, we need to tell the GPU to render to an offset
> within the buffer, so that the data is written into the correct
> miplevel. We do this using a coarse offset (in p
On 04/26/2012 06:54 AM, Paul Berry wrote:
In i965 Gen6, Mesa has for a long time used the "depth coordinate
offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to
render to miplevels other than 0. Unfortunately, this doesn't work,
because these offsets must be aligned to multiples of
On Wed, 02 May 2012 18:32:01 -0700, Chad Versace
wrote:
> Solutions for core Mesa
> ---
>
> As for fixing _mesa_BindFramebufferEXT, I have two ideas.
>
> 1. Enforce in _mesa_BindFramebufferEXT that no more than one of ARB_fbo
>and EXT_fbo is enabled, then clean up its va
- Ursprungligt meddelande -
> This new gbm entry point allows writing data into a gbm bo. The bo
> has to be created with the GBM_BO_USE_WRITE flag, and it's only
> required to work for GBM_BO_USE_CURSOR_64X64 bos.
>
> The gbm API is designed to be the glue layer between EGL and KMS, but
- Ursprungligt meddelande -
> On Thu, May 3, 2012 at 7:47 AM, Jakob Bornecrantz
> wrote:
> > Hi Kristian,
> >
> > s/gbm_bo_write/gbm_bo_write_to_cursor/g and make fail on anything
> > other then cursors and I'm happy. Not making it just happen
> > to work on some hardware really sucks for
On 05/02/2012 02:42 PM, Olivier Galibert wrote:
On Wed, May 02, 2012 at 02:17:31PM -0700, Ian Romanick wrote:
I've been trying to keep this list alphabetized.
Ok.
+ if (ctx->Const.NativeIntegers) {
+ ctx->Extensions.ARB_shader_bit_encoding = GL_TRUE;
+ }
+
Is this actually true?
On Wed, May 02, 2012 at 07:04:57PM -0400, Robert Hooker wrote:
> Otherwise it fails like so:
>
> CC egl_dri2.lo
> In file included from egl_dri2.h:40:0,
> from egl_dri2.c:42:
> ../../../../../../src/egl/wayland/wayland-drm/wayland-drm.h:8:41:
> fatal error: wayland-drm-serve
On 05/02/2012 06:32 PM, Chad Versace wrote:
Mesa has problems in the way it implements glBindFramebuffer and
glBindFramebufferEXT due to both being implemented by an overloaded
_mesa_BindFramebufferEXT. This problem causes an Android app [1] to crash,
and I want your opinion on how we should fix
On Thu, May 3, 2012 at 7:47 AM, Jakob Bornecrantz wrote:
> Hi Kristian,
>
> s/gbm_bo_write/gbm_bo_write_to_cursor/g and make fail on anything
> other then cursors and I'm happy. Not making it just happen
> to work on some hardware really sucks for those that it doesn't
> work on because people wil
On Thu, May 3, 2012 at 7:05 AM, Ander Conselvan de Oliveira
wrote:
> I did a simple test here and the patch worked. I have just a couple of
> comments.
Good points, patch updated.
Kristian
> On 05/02/2012 10:32 PM, Kristian Høgsberg wrote:
>>
>> This new gbm entry point allows writing data into
On 05/03/2012 04:36 AM, Marek Olšák wrote:
On Thu, May 3, 2012 at 3:32 AM, Chad Versace
wrote:
(FYI, if I understand the gallium code, the only drivers that currently
enable both are Intel, swrast, and OSMesa).
Gallium also enables both if packed depth-stencil textures are
supported (w
On 2012-05-03 07:20 +0200, Sven Joachim wrote:
> Building the wayland backend in mesa with wayland from the 0.85 branch
> fails:
>
> ,
> | make[5]: Entering directory
> `/usr/local/src/deb-src/mesa/mesa/build/dri/src/gallium/state_trackers/egl'
> | gcc -c -I. -I../../../../src/gallium/include
Hi Kristian,
s/gbm_bo_write/gbm_bo_write_to_cursor/g and make fail on anything
other then cursors and I'm happy. Not making it just happen
to work on some hardware really sucks for those that it doesn't
work on because people will expect it to work.
Cheers, Jakob.
- Original Message -
>
I did a simple test here and the patch worked. I have just a couple of
comments.
On 05/02/2012 10:32 PM, Kristian Høgsberg wrote:
This new gbm entry point allows writing data into a gbm bo. The bo has
to be created with the GBM_BO_USE_WRITE flag, and it's only required to
work for GBM_BO_USE_C
On Thu, May 3, 2012 at 3:32 AM, Chad Versace
wrote:
> (FYI, if I understand the gallium code, the only drivers that currently
> enable both are Intel, swrast, and OSMesa).
Gallium also enables both if packed depth-stencil textures are
supported (which is the case with most, if not all, driver
When configuring mesa git master with "--enable-xlib-glx", the GL
library does not get installed. I configured mesa like this:
,
| % ./configure --enable-xlib-glx --without-gallium-drivers \
| --without-dri-drivers --disable-egl --prefix=/tmp/mesa
`
and after running make, have the foll
28 matches
Mail list logo
