https://bugs.freedesktop.org/show_bug.cgi?id=31544
Summary: bad format in _mesa_format_to_type_and_comps
Product: Mesa
Version: 7.9
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Prior
On Wed, Nov 10, 2010 at 7:40 PM, Brian Paul wrote:
> On 11/09/2010 09:03 PM, firos ismail wrote:
>
>> Hi all,
>>
>> When comparing the buffers created by X11 and OSMesa i found
>> that the functions that put values to the buffers are different and
>> their logic is different both take dif
On Thu, 2010-11-11 at 01:47 +0800, Jerome Glisse wrote:
> On Wed, Nov 10, 2010 at 12:28 PM, Eric Anholt wrote:
> > On Wed, 10 Nov 2010 08:25:19 +0800, "Xiang, Haihao"
> > wrote:
> >> Any comment? If no problem, I will check in this fix.
> >
> > This should really be part of the core -- all drive
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 30192, which changed state.
Bug 30192 Summary: Doom3-demo segfaults since glsl2 branch merged.
https://bugs.freedesktop.org/show_bug.cgi?id=30192
What|Old Value |New Value
---
https://bugs.freedesktop.org/show_bug.cgi?id=30192
Andy Furniss changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Hi all
We have a bunch of redundant target helpers to wrap screens with debug drivers
and for creating the various software drivers. This series removes all but the
inline one, I picked it since it gives more flexibility for targets and maybe
more importantly is the one that is used in 20 place
Am Mittwoch, den 10.11.2010, 14:11 -0700 schrieb Brian Paul:
> Here's an idea. I may be totally off base (this is off the top of my
> head) but suppose the interlaced texture is:
>
> A B C D (even line)
> e f g h (odd line)
> I J K L (even line)
> m n o p (odd line)
>
> Couldn't you lie to
Am Mittwoch, den 10.11.2010, 15:30 -0500 schrieb Younes Manton:
> Keep in mind that the XvMC interface makes no guarantees about the
> order in which macroblocks are submitted. Also, we're already sorting
> macroblocks by I/P/B type in order to batch draw calls. Otherwise it
> would be possible to
On Wed, 2010-11-10 at 13:24 -0800, Marek Olšák wrote:
> On Wed, Nov 10, 2010 at 9:48 PM, José Fonseca
> mailto:jfons...@vmware.com>> wrote:
> On Wed, 2010-11-10 at 12:29 -0800, Marek Olšák wrote:
> > Required because ATI and NVIDIA DX9 GPUs do not support indirect addressing
> > of temps, inputs,
On Wed, 20 Oct 2010 18:01:10 -0400, Robert Hooker wrote:
> From: Robert Hooker
>
> Signed-off-by: Robert Hooker
Finally pushed this. Sorry for the delay.
pgpB4JqYgtcJr.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedes
On Wed, Nov 10, 2010 at 9:48 PM, José Fonseca wrote:
> On Wed, 2010-11-10 at 12:29 -0800, Marek Olšák wrote:
> > Required because ATI and NVIDIA DX9 GPUs do not support indirect
> addressing
> > of temps, inputs, outputs, and consts (FS-only) or the hw support is so
> > limited that we cannot use
Hi
This patch was cummited on the old ml at sourceforge.net mesa3d-dev
and singned-off-by Dan Nicholson
http://marc.info/?l=mesa3d-dev&m=125970571528105&w=2
but it still not cummited to the code.
/Magnus
---
--- configure.ac.orig 2008-11-17 23:19:38.0 +0100
+++ configure.ac2008
On 11/10/2010 12:31 PM, Christian König wrote:
Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
On 10.11.2010 15:56, Christian König wrote:
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handling
wo
On Wed, 2010-11-10 at 12:29 -0800, Marek Olšák wrote:
> Required because ATI and NVIDIA DX9 GPUs do not support indirect addressing
> of temps, inputs, outputs, and consts (FS-only) or the hw support is so
> limited that we cannot use it.
>
> This should make r300g and possibly nvfx more feature c
On 10.11.2010 20:31, Christian König wrote:
> Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
>> On 10.11.2010 15:56, Christian König wrote:
>>> Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handl
On Wed, Nov 10, 2010 at 9:56 AM, Christian König
wrote:
> I also started to profile the performance of the code a bit, as expected
> we spend far to much time deciding of how and where to draw something
> compared to really drawing something. Up to 50% of the whole cpu time is
> spend in gen_block
Required because ATI and NVIDIA DX9 GPUs do not support indirect addressing
of temps, inputs, outputs, and consts (FS-only) or the hw support is so
limited that we cannot use it.
This should make r300g and possibly nvfx more feature complete.
Signed-off-by: Marek Olšák
---
src/gallium/include/p
On Wed, Nov 10, 2010 at 3:56 PM, Christian König wrote:
> Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
> > Looking (for the first time) at iso13818-2 I think the chroma handling
> > would be part of display rather than decode, though the iso does specify
> > how chroma is laid out
repository split) with CMake.
>
> This is now done in the mesa/demos' cmake branch. Linux, cross MinGW,
> and MSVC (both 32bit and 64bit) build perfectly. I've made a package of
> 32bit and 64bit MSVC binaries and uploaded to
> http://people.freedesktop.org/~jrfonseca/mesade
Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
> On 10.11.2010 15:56, Christian König wrote:
> > Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
> >> Looking (for the first time) at iso13818-2 I think the chroma handling
> >> would be part of display rather than
On Thu, Nov 11, 2010 at 3:08 AM, Clurado cl wrote:
> ok , when i replaced my own build i915_dri.so with the orginal dri driver
> xeglgears works with hw acceleration. ( i used original because with some
> configs x console reports unknown pci id and clients say could not get
> dobule buffered
inGW,
and MSVC (both 32bit and 64bit) build perfectly. I've made a package of
32bit and 64bit MSVC binaries and uploaded to
http://people.freedesktop.org/~jrfonseca/mesademos/mesademos-20101110-windows.7z
I'd like to merge the branch and remove SCons.
On MSVC CMake generates a Visual stud
ok , when i replaced my own build i915_dri.so with the orginal dri driver
xeglgears works with hw acceleration. ( i used original because with some
configs x console reports unknown pci id and clients say could not get
dobule buffered RGB ... )
but opengles1 demos still not working.
libEGL d
On Wed, Nov 10, 2010 at 12:28 PM, Eric Anholt wrote:
> On Wed, 10 Nov 2010 08:25:19 +0800, "Xiang, Haihao"
> wrote:
>> Any comment? If no problem, I will check in this fix.
>
> This should really be part of the core -- all drivers have to flush when
> changing current context.
Agree.
Cheers,
J
On Wed, 10 Nov 2010 08:25:19 +0800, "Xiang, Haihao"
wrote:
> Any comment? If no problem, I will check in this fix.
This should really be part of the core -- all drivers have to flush when
changing current context.
pgp8Q4yysAmQ6.pgp
Description: PGP signature
___
On 10.11.2010 15:56, Christian König wrote:
> Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
>> Looking (for the first time) at iso13818-2 I think the chroma handling
>> would be part of display rather than decode, though the iso does specify
>> how chroma is laid out for fields in
On Wed, Nov 10, 2010 at 11:40 PM, Clurado cl wrote:
>
> Mesa 7.9 from ftp , demos 8.0.1 from ftp
>
>
> when there is no gallium egl driver , without setting EGL_DRIVER=egl_dri2:
>
> egl/opengl/xeglgears :
>
> ./xeglgears
> libEGL debug: added /usr/lib/egl/egl_dri2.so to module array
> libEGL debu
On 11/10/2010 08:44 AM, Francisco Jerez wrote:
Brian Paul writes:
On 11/10/2010 05:41 AM, Francisco Jerez wrote:
Brian Paul writes:
Of course, we _could_ do the comparison with ints but we'd have to
query the number of framebuffer alpha bits, convert the floats to ints
with the right numb
https://bugs.freedesktop.org/show_bug.cgi?id=31514
--- Comment #4 from Brian Paul 2010-11-10 07:47:20 PST ---
BTW, I just added a new piglit test (isbufferobj) for this bug/issue.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail beca
Brian Paul writes:
> On 11/10/2010 05:41 AM, Francisco Jerez wrote:
>> Brian Paul writes:
>>>
>>> Of course, we _could_ do the comparison with ints but we'd have to
>>> query the number of framebuffer alpha bits, convert the floats to ints
>>> with the right number of bits, then compare (to matc
Mesa 7.9 from ftp , demos 8.0.1 from ftp
when there is no gallium egl driver , without setting EGL_DRIVER=egl_dri2:
egl/opengl/xeglgears :
./xeglgears
libEGL debug: added /usr/lib/egl/egl_dri2.so to module array
libEGL debug: added /usr/lib/egl/egl_glx.so to module array
libEGL debug: added /
https://bugs.freedesktop.org/show_bug.cgi?id=31514
--- Comment #3 from Brian Paul 2010-11-10 07:33:38 PST ---
I just ran a test with NVIDIA's driver (version 256.35) and it returns GL_TRUE
like Mesa does. I wonder what AMD's driver does?
This is one of those corner cases where the spec may say
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
> Looking (for the first time) at iso13818-2 I think the chroma handling
> would be part of display rather than decode, though the iso does specify
> how chroma is laid out for fields in 6.1.1.8.
>
> An article that describes the issue
On 11/11/10 01:36, Jerome Glisse wrote:
On Wed, Nov 10, 2010 at 2:36 AM, Russell Shaw wrote:
Hi,
I compiled mesa from sources.
In mesa/src/driclient/src/XF86dri.c, if i use the
api to make a drawable, how can i find the buffer
pixel format?
See my other reply on the wayland mailing list but
On Wed, Nov 10, 2010 at 2:36 AM, Russell Shaw wrote:
> Hi,
> I compiled mesa from sources.
>
> In mesa/src/driclient/src/XF86dri.c, if i use the
> api to make a drawable, how can i find the buffer
> pixel format?
See my other reply on the wayland mailing list but i think you are
trying to achieve
On 11/10/2010 05:41 AM, Francisco Jerez wrote:
Brian Paul writes:
Of course, we _could_ do the comparison with ints but we'd have to
query the number of framebuffer alpha bits, convert the floats to ints
with the right number of bits, then compare (to match the
hardware). It seems to be a lot
On 11/09/2010 09:03 PM, firos ismail wrote:
Hi all,
When comparing the buffers created by X11 and OSMesa i found
that the functions that put values to the buffers are different and
their logic is different both take different origins to put values. Is
this normal or is there any changes
Brian Paul writes:
>
> Of course, we _could_ do the comparison with ints but we'd have to
> query the number of framebuffer alpha bits, convert the floats to ints
> with the right number of bits, then compare (to match the
> hardware). It seems to be a lot of extra work for no good reason.
>
OK, h
38 matches
Mail list logo
