[Mesa3d-dev] [Bug 25847] Enable OpenGL 1.4 support in most commonly used drivers
http://bugs.freedesktop.org/show_bug.cgi?id=25847 --- Comment #4 from Tobias Jakobi liquid.a...@gmx.net 2010-01-02 04:44:37 PST --- Each OpenGL version has a list of mandatory features which must be supported by the GL (graphics library). Of course you could just advertise OpenGL 3.2 support for every hardware driver in Mesa (assuming that the software driver supports all OpenGL 3.2 features) and fall back to SW-rendering as soon as the application uses a features which the hardware doesn't natively support. However that's not how Mesa works. SW-rendering is slow, much slower than HW-accelerated rendering so each driver only advertises a feature-list which it can support (more or less) in hardware. Based on this feature-list the advertised OpenGL version is generated. If the hardware only supports all features that are needed for GL 1.4 but not all features for GL 2.0 - then you only get version 1.4 advertised. !!! Only if all mandatory features for a given GL version are supported in hardware, then you get the version advertised by the driver. !!! There are of course exceptions, like the ARB_npot support on nvidia Geforce FX cards, but that's how it works in general and also for Mesa. Someone please correct me if I stated something wrong :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] fix build breakage
commit c847a13d38d4e8c5f4c386d060dcc8ec09e491a3 caused the gallium build with autoconf/configure/make to fail. --- configs/autoconf.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configs/autoconf.in b/configs/autoconf.in index a7f3c9d..241ac99 100644 --- a/configs/autoconf.in +++ b/configs/autoconf.in @@ -71,7 +71,7 @@ GALLIUM_DRIVERS_DIRS = @GALLIUM_DRIVERS_DIRS@ GALLIUM_WINSYS_DIRS = @GALLIUM_WINSYS_DIRS@ GALLIUM_WINSYS_DRM_DIRS = @GALLIUM_WINSYS_DRM_DIRS@ GALLIUM_STATE_TRACKERS_DIRS = @GALLIUM_STATE_TRACKERS_DIRS@ -GALLIUM_AUXILIARIES = $(foreach DIR,$(GALLIUM_AUXILIARY_DIRS),$(TOP)/src/gallium/auxiliary/$(DIR)/lib$(DIR).a) +GALLIUM_AUXILIARIES = $(TOP)/src/gallium/auxiliary/libgallium.a GALLIUM_DRIVERS = $(foreach DIR,$(GALLIUM_DRIVERS_DIRS),$(TOP)/src/gallium/drivers/$(DIR)/lib$(DIR).a) # Which subdirs under $(TOP)/progs/ to enter: -- 1.6.4.2 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25847] Enable OpenGL 1.4 support in most commonly used drivers
http://bugs.freedesktop.org/show_bug.cgi?id=25847 --- Comment #5 from Ruslan b7.10110...@gmail.com 2010-01-02 07:17:04 PST --- SW-rendering is slow, much slower than HW-accelerated rendering This shouldn't be the reason for refusing to support any features in the driver. OpenGL is not only used for games. So, in many applications it's not required to be too fast. But, existence of any acceleration is always good. Sometimes one will need to use feature which is not supported by hardware, and it's absolutely inefficient to lose all hardware acceleration (via NoAccel) just to get higher GL version to enable this feature. It might be much faster to use the acceleration which hardware supports while using SW for the features it doesn't. Ideally, SW-fallback to support needed GL version should be an option in driconf, so that if an application doesn't need high GL version, it won't see its support and will stay fast. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25847] Enable OpenGL 1.4 support in most commonly used drivers
http://bugs.freedesktop.org/show_bug.cgi?id=25847 --- Comment #6 from Alex Deucher ag...@yahoo.com 2010-01-02 08:02:00 PST --- You can force software rendering with an env var: LIBGL_ALWAYS_SOFTWARE=1 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25847] Enable OpenGL 1.4 support in most commonly used drivers
http://bugs.freedesktop.org/show_bug.cgi?id=25847 --- Comment #7 from Ruslan b7.10110...@gmail.com 2010-01-02 08:19:00 PST --- You can force software rendering Yes, that's just what i don't want ;) What this bug is about is to have Mesa accelerate everything it (given the hardware) can, and do in software what is can't accelerate. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25847] Enable OpenGL 1.4 support in most commonly used drivers
http://bugs.freedesktop.org/show_bug.cgi?id=25847 --- Comment #8 from Joakim Sindholt b...@zhasha.com 2010-01-02 08:52:53 PST --- Listen now, lots and lots of programs will check the extension string to determine whether certain functionality is available. So say you check for GLSL in order to do phong shading but in case it's not there you fall back to ff light. Now we have a problem because that program will see oh, I have GLSL, let's shade away and your application will run at horrendously bad speed. In order to fall back intelligently you will face a slightly harder problem. You can't read from textures in VRAM, and VRAM is where we store them to achieve good speed. Falling back would require either constantly migrating textures between VRAM and GART or just keeping them in GART thus taking a serious performance hit on everything that samples from textures. Now close your bug. I'm tired of getting e-mails of you acting smart. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25847] Enable OpenGL 1.4 support in most commonly used drivers
http://bugs.freedesktop.org/show_bug.cgi?id=25847 Ruslan b7.10110...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25847] Enable OpenGL 1.4 support in most commonly used drivers
http://bugs.freedesktop.org/show_bug.cgi?id=25847 --- Comment #9 from Tobias Jakobi liquid.a...@gmx.net 2010-01-02 09:12:44 PST --- (In reply to comment #7) What this bug is about is to have Mesa accelerate everything it (given the hardware) can, and do in software what is can't accelerate. Not worth the trouble, read what Joakim wrote. With this approach you probably end up with a performance worse than pure software rendering. There might be some corner cases where the mixed-model approach might be slightly faster, but again: it's not worth the trouble. If you just need all fancy GL features and you don't care about performance - use the software renderer. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] fix build breakage
On Sat, Jan 2, 2010 at 5:51 AM, Marc Dietrich marvi...@gmx.de wrote: commit c847a13d38d4e8c5f4c386d060dcc8ec09e491a3 caused the gallium build with autoconf/configure/make to fail. Committed. Thanks! -Brian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] fix build breakage
Thanks. I've hunted down and fixed/removed all other references GALLIUM_AUXILIARY_DIRS variable. Jose From: Brian Paul [brian.e.p...@gmail.com] Sent: Saturday, January 02, 2010 17:34 To: Marc Dietrich Cc: Mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] [PATCH] fix build breakage On Sat, Jan 2, 2010 at 5:51 AM, Marc Dietrich marvi...@gmx.de wrote: commit c847a13d38d4e8c5f4c386d060dcc8ec09e491a3 caused the gallium build with autoconf/configure/make to fail. Committed. Thanks! -Brian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Regression] [bisected] r7xx rendering problems with master branch
Hello list,
The environment:
* Gentoo amd64;
* kernel from the drm-radeon-testing branch of
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 (latest
HEAD);
* lspci says about my card: 01:00.0 VGA compatible controller: ATI
Technologies Inc RV790 [Radeon HD 4800 Series];
* libdrm from master;
* mesa from master;
* radeon ddx from master;
* Xorg server 1.7.4 RC 2.
The testbed: the glsnake screensaver from xscreensaver, and
crack-attack - both render badly with master. The symptoms are that
the patterns rendered to the screen leave some traces behind them -
ultimately, the screen turns completely white with the screensaver
(glsnake is not the one with which that happens).
I have bisected this rendering bug to commit
3728673bd1b974e54858fbab6ff62d3607b0d3f0. The comment says:
Note that there's quite a few tests for ctx-Color.BlendEnabled != 0 in
drivers, etc. Those tests can remain as-is since the mask will be 0 or ~0
unless GL_EXT_draw_buffers2 is enabled.
And indeed, the r600_dri driver is such one, and more specifically, it
seems, r7xx series (such as my card):
f...@erwin ~/src/mesa $ git grep -n BlendEnabled src/mesa/drivers/dri/r600/
src/mesa/drivers/dri/r600/r700_state.c:454: if
(RGBA_LOGICOP_ENABLED(ctx) || !ctx-Color.BlendEnabled) {
Unfortunately, reverting this particular commit is nontrivial :(
--
Francis Galiegue, fgalie...@gmail.com
It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries (Stéphane Faroult, in The
Art of SQL, ISBN 0-596-00894-5)
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Regression] [bisected] r7xx rendering problems with master branch
On Sat, Jan 2, 2010 at 10:21 PM, Francis Galiegue fgalie...@gmail.com wrote: [...] (glsnake is not the one with which that happens). Sorry, I meant not the _only_ one :/ -- Francis Galiegue, fgalie...@gmail.com It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries (Stéphane Faroult, in The Art of SQL, ISBN 0-596-00894-5) -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Removing DRI1 from Intel dri driver
Hi all,
I have a patch series here:
http://cgit.freedesktop.org/~krh/mesa/log/?h=remove-dri1
to remove DRI1 support from the Intel DRI driver. The Intel DDX no
longer supports DRI1 and it makes sense to remove DRI1 support from
the DRI driver as well. I split it up in a series of commits, with
the first one taking the DRI1 (legacy) extension out of the list of
Intel driver extensions. The remaining commits removed pieces of DRI1
only code bit by bit. It should be all dead code, but I did it
piecewise so we can bisect if something breaks in the DRI2 path.
There is also a big commit to rename the remaining
__DRI{screen,drawable,context}Private to
__DRI{screen,drawable,context}. It's a leftover from when I reworked
the DRI driver interface for DRI2. I merged the Private and
non-private structs (it's all private now) and I just left a typedef
in the code to avoid having to do a massive rename. That was probably
stupid and I decided to do the rename now - it turned out to be a
one-line find+sed job... It's straight forward and I don't expect it
to clash with anybodys outstanding work, but I figured I'd mention it
on the list before merging.
Any objections?
cheers,
Kristian
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25863] New: Vega state tracker fail when using multiply, screen, darken and light blend option
http://bugs.freedesktop.org/show_bug.cgi?id=25863 Summary: Vega state tracker fail when using multiply, screen, darken and light blend option Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: igor_trind...@yahoo.com.br Running progs/openvg/trivial/arc i am receiving a segfault when i change the blend mode to VG_BLEND_DARKEN: diff --git a/progs/openvg/trivial/arc.c b/progs/openvg/trivial/arc.c index db686be..492ea38 100644 --- a/progs/openvg/trivial/arc.c +++ b/progs/openvg/trivial/arc.c @@ -51,7 +51,7 @@ init(void) vgSetPaint(vgPaint, VG_FILL_PATH); vgSeti(VG_RENDERING_QUALITY, VG_RENDERING_QUALITY_NONANTIALIASED); -vgSeti(VG_BLEND_MODE, VG_BLEND_SRC_OVER); +vgSeti(VG_BLEND_MODE, VG_BLEND_DARKEN); vgSetf(VG_STROKE_LINE_WIDTH, 2.0f); vgSeti(VG_STROKE_CAP_STYLE, VG_CAP_SQUARE); vgSeti(VG_STROKE_JOIN_STYLE, VG_JOIN_MITER); Backtrace: #0 0x0058d7f6 in get_sampler_varient (unit=0, sampler=0x80a8650, texture=0x0, processor=0) at sp_state_sampler.c:207 #1 0x0058da48 in softpipe_reset_sampler_varients (softpipe=0x8058750) at sp_state_sampler.c:263 #2 0x0058c85d in update_tgsi_samplers (softpipe=0x8058750) at sp_state_derived.c:201 #3 0x0058c9b8 in softpipe_update_derived (softpipe=0x8058750) at sp_state_derived.c:250 #4 0x0057eeba in softpipe_draw_range_elements (pipe=0x8058750, indexBuffer=0x0, indexSize=0, min_index=0, max_index=4294967295, mode=6, start=0, count=19) at sp_draw_arrays.c:128 #5 0x0057f0d5 in softpipe_draw_elements (pipe=0x8058750, indexBuffer=0x0, indexSize=0, mode=6, start=0, count=19) at sp_draw_arrays.c:191 #6 0x0057ee5c in softpipe_draw_arrays (pipe=0x8058750, mode=6, start=0, count=19) at sp_draw_arrays.c:104 #7 0x00ec7d47 in draw_polygon (ctx=0x8091390, poly=0x80b0200) at polygon.c:302 #8 0x00ec8445 in polygon_array_fill (polyarray=0x80ac724, ctx=0x8091390) at polygon.c:462 #9 0x00ed0438 in path_fill (p=0x80ac6f8, mat=0x8091968) at path.c:1565 #10 0x00ed037b in path_render (p=0x80ac6f8, paintModes=3) at path.c:1541 #11 0x00ebf172 in vgDrawPath (path=134924024, paintModes=3) at api_path.c:485 #12 0x0804924a in ellipse (vgPath=134924024, rx=4, ry=4, angle=0) at arc.c:35 #13 0x08049429 in draw () at arc.c:85 #14 0x08049bb0 in event_loop (dpy=0x804d008, win=16777218, egl_dpy=0x8056e10, egl_surf=0x80926a0) at eglcommon.c:171 #15 0x08049f43 in run (argc=1, argv=0xb3d4, init_f=0x8049250 init, resh_f=0x80493a3 reshape, draw_f=0x80493a8 draw, key_f=0) at eglcommon.c:275 #16 0x080496d4 in main (argc=1, argv=0xb3d4) at arc.c:137 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Compile with -fvisibility-hidden by default
We have all functions that need to be visible marked with PUBLIC and this is trimming around 4% off the DRI driver .so size. --- Is there a reason this isn't on by default? cheers, Kristian configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 8504c3c..a0aaba9 100644 --- a/configure.ac +++ b/configure.ac @@ -95,7 +95,7 @@ esac dnl Add flags for gcc and g++ if test x$GCC = xyes; then -CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99 -ffast-math +CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden # Work around aliasing bugs - developers should comment this out CFLAGS=$CFLAGS -fno-strict-aliasing -- 1.6.5.rc2 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/2] opengl-es-v2: Switch to XML based APIspec
On Tue, Dec 08, 2009 at 02:25:14PM +0800, Chia-I Wu wrote: On Sun, Nov 22, 2009 at 9:02 PM, Chia-I Wu olva...@gmail.com wrote: This patch series replaces APIspec.txt by APIspec.xml. The new XML-based format resolves two issues with APIspec.txt * Not easy to read * Code duplication Following the switch, I also have a bunch of fixes to opengl-es-v2 branch that have been sitting on my disk for a while. Instead of waiting for another cycle, I would like to re-send the patch series together with the fixes. It makes a total of 13 patches, gzipped due to the size. The first two patches are unchanged and it switches the branch to XML-based APIspec. Patch 3 adds a sanity check to the new XML parser and patch 4 makes get_gen.py generate _mesa_GetFixedv. It helps eliminates some hundreds of lines of checks in APIspec.xml. Patch 5 and 6 change how special functions are handled. When _es_FooBar cannot be implememented by _mesa_FooBar, the function is called special and requires manual implementation. Special functions were skipped in es_generator.py. This change makes es_generator.py still generate code for them, but only the parameter checking part. It saves the manual implementations from having to perform the checks. Patch 7~9 add new extensions to glapi, APIspec, and glGetString(GL_EXTENSIONS). It also removes extensions that do not belong to OpenGL ES 2.0. Patch 10~12 fix/improve support for GL_OES_texture_cube_map, GL_OES_framebuffer_object, and GL_OES_compressed_paletted_texture respectively. And the last patch adds compressed paletted texture tests to torus demo. This patch series should fix all bugs that I am aware of and can be fixed entirely in the ES overlay. This patch series seems to be forgotten... Any comment? -- Regards, olv -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25631] glNewList segfaults
http://bugs.freedesktop.org/show_bug.cgi?id=25631 Chia-I Wu olva...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #14 from Chia-I Wu olva...@gmail.com 2010-01-02 20:15:26 PST --- It seems the issue has resolved. I am closing this bug as NOTABUG. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Compile with -fvisibility-hidden by default
On Sat, Jan 02, 2010 at 07:01:02PM -0500, Kristian Høgsberg wrote: We have all functions that need to be visible marked with PUBLIC and this is trimming around 4% off the DRI driver .so size. I love this change! It might require another patch, but would it be possible to stop marking functions like _mesa_GenTextures as GLAPIENTRY? I think they are not public either in normal build. --- Is there a reason this isn't on by default? -- Regards, olv -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Sat, Dec 26, 2009 at 03:04:51AM +0100, Luca Barbieri wrote: This patch adds two extensions, EGL_MESA_gallium and GLX_MESA_gallium, which allow an application to directly access the Gallium3D API bypassing OpenGL and using EGL or GLX for general setup. The python state tracker already uses the GLX_MESA_gallium functions (due to a commit by Jose Fonseca), but the functions are not actually implemented. There is already a WGL extension with wglGetGalliumScreenMESA and wglCreateGalliumContextMESA. A wglGetGalliumSurfacesMESA function should probably be added to match the EGL/GLX versions in this patch. It adds 3 functions: (egl|glx)GetGalliumScreenMESA: returns a pipe_screen for an X11 display/screen or an EGL display (egl|glx)CreateGalliumContextMESA: creates a pipe_context for an X11 display/screen or an EGL display (egl|glx)GetGalliumSurfacesMESA: returns all pipe_surface attachments for an X11 drawable or EGL surface For the EGL part, is it possible to define Gallium as a client API? Then the setup code would look like (pseudo code): eglBindAPI(EGL_GALLIUM_API_MESA); ctx = eglCreateContext(); suf = eglCreateWindowSurface(); eglMakeCurrent(ctx, surf); And the new Gallium Client API provides: p_context = g3dGetContext(); fb = g3dGetFramebuffer(); This way, it allows mixing OpenGL/OpenVG/Gallium, and resource sharing between them. -- Regards, olv -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] egl_g3d: Yet another EGL (meta) driver
Hi all, This patch series brings a new EGL (meta) driver, libegl.a. Like libegldrm.a living under state_trackers/egl/, the build process uses it to build various EGL drivers, like egl_i915.so, egl_radeon.so, and etc. I've only tested egl_i915. myself, and others are only compile tested. This driver should be more flexible/complete than the others. After it is tested and accepted, I want to remove egl_softpipe and egl_xdri, as they are deprecated by this driver. I also plan to add support for EGL_MESA_screen_surface and replace state_trackers/egl/. This driver consists of three part * EGL Driver Interface * Native Display(s) * State Tracker Loader The first part allows it to be loaded as an EGL driver, and all common functions are implemented. The second part abstracts a native display. A native display is the X server on most Linux desktops. But it may also be KMS, Android, or others. The abstraction makes it easy to support a new native display. Right now, there is only support for X server. It supports XImage/XShmImage for software rendering. And it also supports DRI2/GLX when the X server supports them. It talks the protocol directly and there is no dependency on libGL. It will ask the server for the driver name, and if the hardware pipe driver matches, it will be used. The detection is done at runtime and there is a fallback mechanism. One may also force the use of the software rendering by setting the env variable EGL_SOFTWARE=1. This should be the first time we have accelerated OpenVG and OpenGL ES on X11. All progs/egl/x* should render correctly with the new driver. All progs/openvg/* work too. But some of the OpenVG demos render incorrectly when used with the i915 pipe driver. I don't have other graphics hardwares that help me identify where the problem is :( The last part allows multiple client APIs to be used at the same time. Currently, the state tracker API is defined in st_public.h. Difference state trackers (say, OpenVG and OpenGL) define the same API that the EGL cannot distinguish. This driver solves the problem through the use of dladdr(). This is supposed to be temporary. I want to rework st_public.h after figuring out what a state tracker should look like. It might base on http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg09789.html This is kinda a lenghty mail. Thank you for the patience and Happy New Year! -- Regards, olv egl_g3d.tar.gz Description: Binary data -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
