[Mesa-dev] About OpenGL QB stereo support..
Hi, first sorry if not is the correct place to post it but I was thinking that with open source Sandy Bridge and AMD 68xx cards support that ship with Displayport 1.2 (AMD only) and HDMI1.4(both) connectors supporting 3d stereo output if could mesa developers expose support for it.. i.e. mesa ogl driver expose support for OGL QB stereo.. of course that perhaps should require changes to drm stack or both amd and intel open source drivers to setup correct stereo frame packing output in this outputs.. that could add an advantage of open source drivers to propietary drivers which only expose ogl stereo support for professional cards.. and even then i think there is no currently support for ogl qb stereo support via hdmi 1.4 nor in Nvidia and AMD worlds.. also this could be a good effort to port all stereo madness to linux now that seem even MVC hardware decoding is supported on both Sandy Bridge and AMD 68xx cards.. that could be exposed via VAAPI for SandyBrige (I'm posting on libva dev list) or new OpenDecode AMD API which already exposes that support (currently Windows world only but some OCL developers have asked AMD to support also Linux).. thanks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): r600g: texture instructions also work fine with TGSI_FILE_INPUT
On Mit, 2011-01-12 at 20:46 +0100, Christian König wrote: I found the bug, fixed it and pushed the fix to master. With this optimisation a simple shader which just samples a texture won't have any alu instructions any more. Since we look only at alu instructions to determine the maximum gpu count used whe end up with a gpu count of 0. Thanks for the help, Thank you for the fix and improvements, working great now. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] fix fbo-srgb on 965
On 13 January 2011 06:49, Dave Airlie airl...@gmail.com wrote: I'd really like to make sure someone else has read EXT_texture_sRGB and agrees with me ;-) Makes sense to me at least. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] st/mesa: Set samplers views' first_level.
On 4 January 2011 22:05, Henri Verbeet hverb...@gmail.com wrote: Base level and min LOD aren't equivalent. In particular, min LOD has no effect on image array selection for magnification and non-mipmapped minification. --- src/mesa/state_tracker/st_atom_sampler.c | 9 +++-- src/mesa/state_tracker/st_atom_texture.c | 4 +++- 2 files changed, 6 insertions(+), 7 deletions(-) Did this get lost? Otherwise I'll probably push this sometime during the next few days. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] fix fbo-srgb on 965
On Thu, Jan 13, 2011 at 8:35 PM, Henri Verbeet hverb...@gmail.com wrote: On 13 January 2011 06:49, Dave Airlie airl...@gmail.com wrote: I'd really like to make sure someone else has read EXT_texture_sRGB and agrees with me ;-) Makes sense to me at least. Thanks, and Kenneth also ran my tests against the binaries and they seem to agree. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33053] New: SIGSEGV at brw_wm_populate_key during KDE login with gallium sw renderer enabled
https://bugs.freedesktop.org/show_bug.cgi?id=33053
Summary: SIGSEGV at brw_wm_populate_key during KDE login with
gallium sw renderer enabled
Product: Mesa
Version: 7.10
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: hugo.mildenber...@web.de
using mesa-7.10 with --enable-asm on Gentoo/hardened with Intel Mobile GM965:
# eselect mesa list
i915 (Intel 915, 945)
[1] classic
[2] gallium *
i965 (Intel 965, G/Q3x, G/Q4x)
[1] classic
[2] gallium *
r300 (Radeon R300-R500)
r600 (Radeon R600-R700, Evergreen, Northern Islands)
sw (Software renderer)
[1] classic
[2] gallium *
While all other configurations have been unusable due to screen corruption, the
above listed configuration crashed xorg-server-1.9.3.901, obviously while KDE
was trying to switch to OpenGL during login.
With tex being NULL, this line of brw_texture should be the point where mesa
finally triggers signal 11:
90 assert(tex-b.vtbl == brw_texture_vtbl);
Since brw_texture doesn't that much except casting a pointer,
that line should probably read
assert(tex tex-b.vtbl == brw_texture_vtbl);
#gdb $(which X) --core=0:0-X.core
[...]
(gdb) bt
#0 0x0328966e86d5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0328966e99d5 in abort () at abort.c:92
#2 0x00425a1714ae in OsAbort () at utils.c:1274
#3 0x00425a17dbcd in ddxGiveUp () at xf86Init.c:940
#4 0x00425a16f0ad in AbortServer () at log.c:424
#5 0x00425a16f8f0 in FatalError (f=0x425a286d68 Caught signal %d (%s).
Server aborting\n) at log.c:552
#6 0x00425a17078e in OsSigHandler (signo=11, sip=0x8, unused=value
optimized out) at osinit.c:156
#7 signal handler called
#8 0x0328931a0d04 in brw_wm_populate_key (brw=0x425c4a0d30,
key=0x3f523000780) at brw_wm.c:256
#9 0x0328931a0e51 in brw_prepare_wm_prog (brw=0x425c4a0d30) at
brw_wm.c:287
#10 0x03289319b51d in brw_validate_state (brw=0x425c4a0d30) at
brw_state_upload.c:179
#11 0x03289318da3d in try_draw_range_elements (brw=0x425c4a0d30, indexed=0
'\000', hw_prim=7, start=0, count=4) at brw_draw.c:151
#12 0x03289318dbcf in brw_draw_vbo (pipe=0x425c4a0d30, info=0x3f523000dd0)
at brw_draw.c:209
#13 0x03289326dff7 in st_draw_vbo (ctx=0x425c4b8d90, arrays=0x425c4e0a38,
prims=0x425c4df154, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
min_index=0, max_index=3)
at state_tracker/st_draw.c:732
#14 0x03289334d44a in vbo_exec_vtx_flush (exec=0x425c4dee70, unmap=1
'\001') at vbo/vbo_exec_draw.c:381
#15 0x03289334933a in vbo_exec_FlushVertices_internal (ctx=0x425c4b8d90,
unmap=1 '\001') at vbo/vbo_exec_api.c:911
#16 0x0328933493aa in vbo_exec_FlushVertices (ctx=0x425c4b8d90, flags=1) at
vbo/vbo_exec_api.c:945
#17 0x0328932f72dc in _mesa_PopAttrib () at main/attrib.c:858
#18 0x032894b42983 in __glXDisp_Render (cl=value optimized out,
pc=0x3288f6aad88 \004) at glxcmds.c:1854
#19 0x032894b46cd2 in __glXDispatch (client=0x425c4340a0) at glxext.c:605
#20 0x00425a13bda9 in Dispatch () at dispatch.c:432
#21 0x00425a1313aa in main (argc=10, argv=0x3f5230012b8, envp=value
optimized out) at main.c:291
#
(gdb) list brw_wm.c:254
249
250/* PIPE_NEW_RAST */
251key-flat_shade = brw-curr.rast-templ.flatshade;
252
253
254/* PIPE_NEW_BOUND_TEXTURES */
255for (i = 0; i brw-curr.num_fragment_sampler_views; i++) {
256 const struct brw_texture *tex =
brw_texture(brw-curr.fragment_sampler_views[i]-texture);
257
258 if (tex-b.b.format == PIPE_FORMAT_UYVY)
(gdb) sele 8
(gdb) print brw-curr.fragment_sampler_views
$1 = {0x0 repeats 16 times}
(gdb) list brw_texture
87 static INLINE struct brw_texture *brw_texture( struct pipe_resource
*resource )
88 {
89 struct brw_texture *tex = (struct brw_texture *)resource;
90 assert(tex-b.vtbl == brw_texture_vtbl);
91 return tex;
92 }
(gdb) bt f
#0 0x0328966e86d5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar = 0
pid = value optimized out
selftid = 3500
#1 0x0328966e99d5 in abort () at abort.c:92
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x261238, sa_sigaction =
0x261238}, sa_mask = {__val = {284983128240, 284983129872, 285011915848, 2,
3472885982485,
3472857221992, 3472887930880, 0, 4294967295, 0, 1, 4030696, 0,
3472830695552, 4, 284978798592}}, sa_flags = -1742586047, sa_restorer =
0x420001}
sigs = {__val = {32, 0 repeats 15 times}}
#2 0x00425a1714ae in OsAbort () at utils.c:1274
No locals.
#3 0x00425a17dbcd in ddxGiveUp () at xf86Init.c:940
i = value optimized out
#4
[Mesa-dev] [Bug 33053] SIGSEGV at brw_wm_populate_key during KDE login with gallium sw renderer enabled
https://bugs.freedesktop.org/show_bug.cgi?id=33053 Jakob Bornecrantz wallbra...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Jakob Bornecrantz wallbra...@gmail.com 2011-01-13 05:09:56 PST --- Don't use the Intel gallium drivers (especially not the i965 one) they are not supported in anyway. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri_util: fail driCreateNewScreen if InitScreen is NULL
I forgot to mention: this will give us a working X server with
_software_ rendering, instead of a segfaulting X.
2011/1/13 Paulo Zanoni pzan...@mandriva.com:
Without this, X doesn't start with UMS on r300g.
Signed-off-by: Paulo Zanoni pzan...@mandriva.com
---
Sending patch as discussed in #radeon
Tested with mesa 7.10. If the patch is accepted, please backport to 7.10.
src/mesa/drivers/dri/common/dri_util.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index a5b71bd..bf8cf6e 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -790,6 +790,9 @@ driCreateNewScreen(int scrn,
static const __DRIextension *emptyExtensionList[] = { NULL };
__DRIscreen *psp;
+ if (driDriverAPI.InitScreen == NULL)
+ return NULL;
+
psp = calloc(1, sizeof *psp);
if (!psp)
return NULL;
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Paulo Zanoni
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri_util: fail driCreateNewScreen if InitScreen is NULL
On 01/13/2011 05:59 AM, Paulo Zanoni wrote: Without this, X doesn't start with UMS on r300g. Committed. Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa-demos 4/6] Rename opengles2/tri to opengles2/es2tri
On 01/12/2011 11:51 AM, Paulo Zanoni wrote: 2011/1/6 Paulo Zanonipzan...@mandriva.com: diff --git a/src/egl/opengles2/.gitignore b/src/egl/opengles2/.gitignore index bbfb095..8e4bc34 100644 --- a/src/egl/opengles2/.gitignore +++ b/src/egl/opengles2/.gitignore @@ -1,3 +1,3 @@ es2gears +es2tri es2_info -tri For some reason this chunk wasn't committed... See: http://cgit.freedesktop.org/mesa/demos/commit/?id=024df5987e4da9288cc9c62dc71df1812d84a347 Why? So I provide a new patch with the same chunk + updated .gitignore for openvg demos (I wasn't compiling them before) + the recently-added eglkms binary. Patch is attached. Committed. Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About OpenGL QB stereo support..
On Thu, 13 Jan 2011 14:18:01 +0200, Corbin Simpson mostawesomed...@gmail.com wrote: 12, 2011 at 3:47 PM, rtfss none rtf...@gmail.com wrote: Hi, first sorry if not is the correct place to post it but I was thinking that with open source Sandy Bridge and AMD 68xx cards support that ship with Displayport 1.2 (AMD only) and HDMI1.4(both) connectors supporting 3d stereo output if could mesa developers expose support for it.. i.e. mesa ogl driver expose support for OGL QB stereo.. of course that perhaps should require changes to drm stack or both amd and intel open source drivers to setup correct stereo frame packing output in this outputs.. that could add an advantage of open source drivers to propietary drivers which only expose ogl stereo support for professional cards.. and even then i think there is no currently support for ogl qb stereo support via hdmi 1.4 nor in Nvidia and AMD worlds.. also this could be a good effort to port all stereo madness to linux now that seem even MVC hardware decoding is supported on both Sandy Bridge and AMD 68xx cards.. that could be exposed via VAAPI for SandyBrige (I'm posting on libva dev list) or new OpenDecode AMD API which already exposes that support (currently Windows world only but some OCL developers have asked AMD to support also Linux).. DRI and GLX have all the correct support for GL_STEREO, but none of the open drivers implement it as far as I know. This would probably be a non-trivial thing to implement. Do we have the necessary documentation to support quad-buffer stereo? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] GL fixed function fragment shaders
If we have a reliable ARB shader to glsl ir coverter, we could just eliminate mesa ir from this chain. So we should get either glsl-tgsi or arb-glsl-tgsi. -- Lucas Am Donnerstag, den 13.01.2011, 17:40 +0100 schrieb Roland Scheidegger: Am 12.01.2011 23:04, schrieb Eric Anholt: This is a work-in-progress patch series to switch texenvprogram.c from generating ARB_fp style Mesa IR to generating GLSL IR as its product. For drivers without native GLSL codegen, that is then turned into the Mesa IR that can be consumed. However, for 965 we don't use the Mesa IR product and just use the GLSL output, producing much better code thanks to the new backend. This is part of a long term goal to get Mesa drivers off of Mesa IR and producing their instruction stream directly from the GLSL IR. I'm not planning on committing this series immediately, as I've still got a regression in the 965 driver with texrect-many on the last commit. As a comparison, here's one of the shaders from openarena before: So what's the code looking like after conversion to mesa IR? As long as it's not worse than the original I guess this should be ok, though for those drivers consuming mesa IR I guess it's just more cpu time without any real benefit? For gallium we should probably address this some way or another, it seems quite backward to do ff-glsl-mesa ir-tgsi. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): i965: Remove unnecessary headers.
-Original Message- From: mesa-dev-bounces+vlee=vmware@lists.freedesktop.org [mailto:mesa- dev-bounces+vlee=vmware@lists.freedesktop.org] On Behalf Of Ian Romanick Sent: Thursday, January 13, 2011 10:43 AM To: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] Mesa (master): i965: Remove unnecessary headers. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/13/2011 09:29 AM, Vinson Lee wrote: Module: Mesa Branch: master Commit: 1f6693033256123ec5cf6f186e5cfb1679e523d3 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=1f6693033256123ec5cf6f186 e5cfb1679e523d3 Author: Vinson Lee v...@vmware.com Date: Thu Jan 13 09:28:47 2011 -0800 i965: Remove unnecessary headers. Does this actually provide any tangible benefit to anyone? All of the spurious header file frobbing has caused several irritations for me, at least: 1. Some commonly used things, like MIN2, MAX2, and ELEMENTS, have moved. This causes frustration when writing new code. 2. The changes cause massive invalidations of my compiler cache. As a result, my average build times are longer. I can only assume that the perceived benefit of all these changes is reduced build time. If there's no benefit, it just feels like spam. The purpose is to reduce build times and improve throughput in automated testing. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vR7kACgkQX1gOwKyEAw+UJQCgkYl9abnukp9/atDnujvdmnok iXoAoJ8MU7e9wbqbezyGJ/QioSq41Jbf =X0lB -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33071] New: xorg session stops due to 3d plotting
https://bugs.freedesktop.org/show_bug.cgi?id=33071 Summary: xorg session stops due to 3d plotting Product: Mesa Version: 7.9 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: GLX AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: m...@stro.at Created an attachment (id=41981) -- (https://bugs.freedesktop.org/attachment.cgi?id=41981) Xorg debug gdb backtrace of the crash mesa 7.9 linux-2.6 2.6.37 X.Org X Server 1.7.7 Just opening a 3d plot in mathematica crashes the session independetly if radeon driver is latest master as of today or the Debian Lenny 6.13.1 Hardware is Evergreen: 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 545 0] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e134 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 44 Region 0: Memory at d000 (64-bit, prefetchable) [size=256M] Region 2: Memory at fe62 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at e000 [size=256] Expansion ROM at fe60 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s 4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 256 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 64ns, L1 1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee0 Data: 4089 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 ? Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About OpenGL QB stereo support..
On Thu, Jan 13, 2011 at 2:35 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/13/2011 06:51 AM, Stefanos A. wrote: On Thu, 13 Jan 2011 14:18:01 +0200, Corbin Simpson mostawesomed...@gmail.com wrote: 12, 2011 at 3:47 PM, rtfss none rtf...@gmail.com wrote: Hi, first sorry if not is the correct place to post it but I was thinking that with open source Sandy Bridge and AMD 68xx cards support that ship with Displayport 1.2 (AMD only) and HDMI1.4(both) connectors supporting 3d stereo output if could mesa developers expose support for it.. i.e. mesa ogl driver expose support for OGL QB stereo.. of course that perhaps should require changes to drm stack or both amd and intel open source drivers to setup correct stereo frame packing output in this outputs.. that could add an advantage of open source drivers to propietary drivers which only expose ogl stereo support for professional cards.. and even then i think there is no currently support for ogl qb stereo support via hdmi 1.4 nor in Nvidia and AMD worlds.. also this could be a good effort to port all stereo madness to linux now that seem even MVC hardware decoding is supported on both Sandy Bridge and AMD 68xx cards.. that could be exposed via VAAPI for SandyBrige (I'm posting on libva dev list) or new OpenDecode AMD API which already exposes that support (currently Windows world only but some OCL developers have asked AMD to support also Linux).. DRI and GLX have all the correct support for GL_STEREO, but none of the open drivers implement it as far as I know. This would probably be a non-trivial thing to implement. Do we have the necessary documentation to support quad-buffer stereo? I'm not sure. I think HDMI does stereo differently than the traditional approach. The traditional way is to just switch between the left and right buffers each vertical blank. To get this working we'll need some support in X and in the kernel. We don't need any documentation to do the old way, but if HDMI is, in fact, different, we may need some additional documentation. HDMI indeed does it differently; in fact there are several methods supported depending on the hw. There are special HDMI 3D packets required for the source and the sink decide what methods they each support and which one they are going to use. See this page for more info: http://thedigitallifestyle.com/cs/tdl/b/custom/archive/2010/03/26/making-sense-out-of-hdmi-1-4-performance-and-the-cea_1920_s-861-infoframes-_2d00_-installment-027.aspx The data is sent to the TV differently depending on the method the source and sink work out. Alex Since HDMI is proprietary, it may be (legally) impossible to make some of the documentation public. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vU/gACgkQX1gOwKyEAw875gCfW8mbrWC0G8RV6h/BTWfxtnMt IxYAniFjkQrCE5Q8kkdKffWR84ZURdYQ =pJmz -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About OpenGL QB stereo support..
On Thu, 13 Jan 2011 21:35:20 +0200, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/13/2011 06:51 AM, Stefanos A. wrote: On Thu, 13 Jan 2011 14:18:01 +0200, Corbin Simpson mostawesomed...@gmail.com wrote: 12, 2011 at 3:47 PM, rtfss none rtf...@gmail.com wrote: Hi, first sorry if not is the correct place to post it but I was thinking that with open source Sandy Bridge and AMD 68xx cards support that ship with Displayport 1.2 (AMD only) and HDMI1.4(both) connectors supporting 3d stereo output if could mesa developers expose support for it.. i.e. mesa ogl driver expose support for OGL QB stereo.. of course that perhaps should require changes to drm stack or both amd and intel open source drivers to setup correct stereo frame packing output in this outputs.. that could add an advantage of open source drivers to propietary drivers which only expose ogl stereo support for professional cards.. and even then i think there is no currently support for ogl qb stereo support via hdmi 1.4 nor in Nvidia and AMD worlds.. also this could be a good effort to port all stereo madness to linux now that seem even MVC hardware decoding is supported on both Sandy Bridge and AMD 68xx cards.. that could be exposed via VAAPI for SandyBrige (I'm posting on libva dev list) or new OpenDecode AMD API which already exposes that support (currently Windows world only but some OCL developers have asked AMD to support also Linux).. DRI and GLX have all the correct support for GL_STEREO, but none of the open drivers implement it as far as I know. This would probably be a non-trivial thing to implement. Do we have the necessary documentation to support quad-buffer stereo? I'm not sure. I think HDMI does stereo differently than the traditional approach. The traditional way is to just switch between the left and right buffers each vertical blank. What about configurations that display both buffers on two different monitors at the same time? Some cards also have distinct output ports for an active sync signal, although that can probably be ignored for now. The HDMI 3d spec is available for download *without* an HDMI Adopter Agreement. It can be found here: http://www.hdmi.org/manufacturer/specification.aspx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] GL fixed function fragment shaders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/13/2011 08:45 AM, Lucas Stach wrote: If we have a reliable ARB shader to glsl ir coverter, we could just eliminate mesa ir from this chain. So we should get either glsl-tgsi or arb-glsl-tgsi. I had been working on that before our crunch to get Sandy Bridge support finished. I plan to resume in a week or so. The work I did for EXT_separate_shader_objects was to support compiling the assembly shaders to GLSL IR. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vcqkACgkQX1gOwKyEAw9RLgCgjaSsrNOycQDakbUL+S6G0lUm +NMAniUmU15xdB8bRrb0jyV7Res5qlWB =Wjdf -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31907] [SEGFAULT] state_tracker/st_mesa_to_tgsi.c:193: return t-outputs[t-outputMapping[index]];
https://bugs.freedesktop.org/show_bug.cgi?id=31907 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Sven Arvidsson s...@whiz.se 2011-01-13 13:54:14 PST --- Just tried git master, it's working fine now! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Common GL usage pattern where mesa/gallium is underperforming
Hi, This mail is mostly a remainder to myself and also a try to get someone to look into it before i myself got more time on this :) A common GLSL pattern is : glUseProgram(Program1); glActiveTexture(GL_TEXTURE0 + 0); glBindTexture(...); glActiveTexture(GL_TEXTURE0 + 1); glBindTexture(...); ... glUniform4fARB(...); ... glDraw() glUseProgram(Program2); glActiveTexture(GL_TEXTURE0 + 0); glBindTexture(...); glActiveTexture(GL_TEXTURE0 + 1); glBindTexture(...); ... glUniform4fARB(...); ... glDraw() Such usage pattern shouldn't trigger many computation inside mesa as we are not modifying texture object state or doing anythings fancy, it's just about switching btw GLSL program and textures. Which sounds like a very common pattern for any GL program that does somethings else than spinning gears :) I added glslstateschange to perf in mesa demos to test the performances in front of such usage pattern. Here is some results (core-i5 3Ghz, difference with closed driver are much worse with slower CPU) : noop105.0 thousand change/sec nouveau 13.0 thousand change/sec fglrx-nosmp 57.5 thousand change/sec fglrx 73.4 thousand change/sec nvidia-nosmp 158.8 thousand change/sec nvidia277.8 thousand change/sec All profiles/datas can be downloaded at http://people.freedesktop.org/~glisse/results/ Obviously the noop driver shows that we are severly underperforming as we are slower than the closed nvidia driver while performing no real rendering, and we don't outperform fglrx by that much. Profiling of the noop driver and also of nexuiz (which has similar pattern) shows a couple of guilty points. Biggest offender is the recreation of sampler each time a texture is bind. The update_samplers (st_atom_sampler.c) memset their is likely useless, but the true optimization is to build sampler state along with the sampler_view_state as the only variable that doesn't came from the texture object is the lod bias value (unless i missed somethings). So idea is to build sampler along sampler_view when a texture object is finalized and to update this sampler state in update_sampler only if the lod bias value change, this should avoid a lot of cso creation overhead and speedup driver. I am not sure why update_textures shows so much in profile, my guess is that pipe_sampler_view_reference is burning cpu cycle as we likely have a lot of texture unit. Texture state is also a big offender, mesa revalidate texture state texture coordinate generation each time a new shader program is bound. Plan here is to compute a mask for (see update_texture_state main/texstate.c) _EnabledUnits _GenFlags _TexGenEnabled for each program (compute this mask from program information as it's constant with the program) and only recompute state if we see states changes in the masked unit (ie unit that affect the bound program). I will get back to this optimization latter (in couple weeks hopefully), but if you have more idea or if someone remember of an easy improvement that can help for this situations that would be welcome :) Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
