[Mesa3d-dev] [Bug 6070] arb_vertex_program seems dependant on nv_vertex_program at least for glGet
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6070 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of i810 and i915 dri drivers?
Donnie Berkholz wrote: Chris Fairles wrote: I maintain an handful of Xgl packages for a distro (gentoo) and I've had several users report errors with the i915_dri.so (and potentially the i810_dri.so) drivers from mesa-cvs. Where do you maintain these things? Are they more useful or functional in some way than hanno's overlay at http://svn.hboeck.de/xgl-overlay/ ? Thanks, Donnie * Application(s) deleted before forwarding http://www.tripthelight.net/xgloverlay It's a fork of hanno's. There was a required patch to glproto for mesa-cvs to compile after the EXT_framebuffer_object extension was added. I patched glproto myself and shared my ebuild with a few others. It worked, people kept requesting it so eventually i just started maintaining my own overlay tossing it up on an svn server for others to access. I also added kdelibs with a ksystray patch (for kde people using xgl) along with the opacity plugin and transset-df-5 (whichever floats your boat). I also include the i915_drm.h from 2.6.16-rc4 for those with 2.6.15 so she at least compiles for i810/i915 (some i915_last_dispatch def'n not in 2.6.15's). People with i810/i915 cards haven't been able to get xgl to work however, so I thought I'd start figuring out why. People using ubuntu's install method seem to have it working (maybe using older snapshot, not sure)... maybe without direct accel, can't recall. Chris (p.s. thanks for the work on xorg7 for all us gentooers ) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 6070] arb_vertex_program seems dependant on nv_vertex_program at least for glGet
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6070 --- Additional Comments From [EMAIL PROTECTED] 2006-03-01 08:47 --- I've fixed up the get_gen.py code to make it easy to check for two extensions when doing error checking. The query for GL_VERTEX_PROGRAM_NV/GL_VERTEX_PROGRAM_ARB, for example, now checks for GL_NV_vertex_program or GL_ARB_vertex_program. TO DO: quite a few other queries need to be updated to check for the ARB extension in addition to NV extension. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of i810 and i915 dri drivers?
Chris Fairles wrote: > I maintain an handful of Xgl packages for a distro (gentoo) and I've had > several users report errors with the i915_dri.so (and potentially the > i810_dri.so) drivers from mesa-cvs. Where do you maintain these things? Are they more useful or functional in some way than hanno's overlay at http://svn.hboeck.de/xgl-overlay/ ? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [Mesa3d-dev] Status of i810 and i915 dri drivers?
On Tue, Feb 28, 2006 at 01:02:24PM -0500, Chris Fairles wrote: > I maintain an handful of Xgl packages for a distro (gentoo) and I've had > several users report errors with the i915_dri.so (and potentially the > i810_dri.so) drivers from mesa-cvs. > > This is a typical error when loading Xgl: > > X Error of failed request: BadLength (poly request too large or internal > Xlib length error) > Major opcode of failed request: 159 (GLX) > Minor opcode of failed request: 1 (X_GLXRender) > Serial number of failed request: 93 > Current serial number in output stream: 94 > > Typical output of "LIBGL_DEBUG=verbose glxgears" looks like: > libGL: XF86DRIGetClientDriverName: 1.4.1 i915 (screen 0) > libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/i915_dri.so > drmOpenByBusid: Searching for BusID pci::00:02.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 4, (OK) > drmOpenByBusid: drmOpenMinor returns 4 > drmOpenByBusid: drmGetBusid reports pci::00:02.0 > libGL error: > i915 DRI driver expected DDX version 1-1.5.x but got version 1.4.1 > libGL warning: 3D driver returned no fbconfigs. > libGL error: InitDriver failed > libGL error: reverting to (slow) indirect rendering > > > > I'm VERY new to this and its a lot to take in at first... just want to > develop an understanding of if it shouldnt work, why. If it should, why > isn't it. Plus the fact i dont own an intel i810/i915 card doesnt help > with testing! > > Perhaps I should be asking the xorg/xgl people? > > Any info would be great. If you're using Mesa CVS, you also need to be using xorg-server and xf86-video-i810 CVS, at this juncture. Cheers, Daniel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 6070] New: arb_vertex_program seems dependant on nv_vertex_program at least for glGet
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6070 Summary: arb_vertex_program seems dependant on nv_vertex_program at least for glGet Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] If a driver announces arb_vertex_program but not nv_vertex_program, there are some problems. Both extensions share some state & enums, but this doesn't seem to be reflected everywhere correctly. At least the get functions only check for nv_vertex_program and not arb_vertex_program (for instance a glGet with GL_PROGRAM_ERROR_POSITION_NV (same as GL_PROGRAM_ERROR_POSITION_ARB) will return GL_INVALID_VALUE if only arb_vertex_program is present). There seems to be a similar issue with nv_fragment_program and arb_fragment_program on first sight (things like getting GL_MAX_TEXTURE_COORD_UNITS). Doom3 / Quake4 hit that often (though announcing the nv versions doesn't make it look any better...) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Status of i810 and i915 dri drivers?
Greetings, I maintain an handful of Xgl packages for a distro (gentoo) and I've had several users report errors with the i915_dri.so (and potentially the i810_dri.so) drivers from mesa-cvs. This is a typical error when loading Xgl: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 159 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 93 Current serial number in output stream: 94 Typical output of "LIBGL_DEBUG=verbose glxgears" looks like: libGL: XF86DRIGetClientDriverName: 1.4.1 i915 (screen 0) libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/i915_dri.so drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::00:02.0 libGL error: i915 DRI driver expected DDX version 1-1.5.x but got version 1.4.1 libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering I'm VERY new to this and its a lot to take in at first... just want to develop an understanding of if it shouldnt work, why. If it should, why isn't it. Plus the fact i dont own an intel i810/i915 card doesnt help with testing! Perhaps I should be asking the xorg/xgl people? Any info would be great. Thanks, Chris --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] arbfslight demo not working
OK, I've checked in a few fixes that allows the demo to work on Linux. Basically a raster-enable flag wasn't getting set and the x11 driver wasn't choosing the appropriate triangle function. -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] arbfslight demo not working
Gonz Hauser wrote: Hello, For me arbfslight demo works with Visual C++ 2005 Express Edition under Windows but not with "make linux-debug" with gcc 4.0.2 under Linux (Debian). Is this supposed to work? Michael said it works on Windows for him. It doesn't work on Linux for me. If I find a little time today I'll see if it's something simple... -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] arbfslight demo not working
Hello, For me arbfslight demo works with Visual C++ 2005 Express Edition under Windows but not with "make linux-debug" with gcc 4.0.2 under Linux (Debian). Is this supposed to work? GH ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)
On 27/02/06, Keith Whitwell <[EMAIL PROTECTED]> wrote: > Michal Krol wrote: > > CVSROOT: /cvs/mesa > > Module name: Mesa > > Repository: Mesa/windows/VC6/mesa/osmesa/ > > Changes by: [EMAIL PROTECTED] 06/02/27 14:41:42 > > > > Log message: > > More GLSL code: > > - add x86 code generator; > > Michal, > > I can't tell you how pleased I am to see the rtasm/ code getting used > for this! It looks like you've taken it to the next level in terms of > applying it to a complex problem domain... How complete is the work > you've done? The slang_execute_x86.c is fully functional, although it does not have any optimization. It is 10 x faster than the interpreter, so it is enough for now, there are other priorities. > Are there any glaring problems with using the assembler, > or things that should be changed? > > Let me know if there's anything I can clarify or help with... > I have spotted some minor bug in the rtasm (see comments in the slang_execute_x86.c). Also I need literal arguments for some opcodes (PUSH, TEST) and 8-bit jumps. I can add this myself, but not as elegant as you can. -- Pozdrawiam, Michal Krol --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
