headers
bugzilla-daemon | 1 Feb 2005 01:31

[Bug 2428] Remove useless #ifdef GLX_DIRECT_RENDERING from drivers

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=2428          

------- Additional Comments From ajax <at> nwnk.net  2005-01-31 16:31 -------
the current thinking is that accelerated indirect GLX involves loading DRI
drivers, preferably the same ones that are loaded by the clients.  from the
driver's perspective, they're always doing "direct rendering" because they're
always talking directly to the hardware.  the X server is just another DRI
client in this case.

backing this out would imply that we want two sets of drivers, one
client-loadable and one server-loadable.  i don't think we want that.  and it
still wouldn't be correct, because not all the drivers even had these ifdefs
(none of the intel drivers, trident, unichrome).  and the define in question
didn't even delineate a consistent set of functionality in the drivers that did
have it (practically everything inside the ifdef for mach64 versus GetLock and
two state emits for mga).

it didn't define a useful API, and we couldn't build with it off.  there's no
functional change here.  if we do want distinct drivers for client versus
server, then we can define that API when we are actually at the point of having
libglx even capable of loading drivers.  and if we do so it can have a more
useful name than GLX_DIRECT_RENDERING since by the time you're down in the
driver you don't know or care if it's GLX, as opposed to say EGL.

GLX_DIRECT_RENDERING should really only mean "build the GLX client library to
know how to load DRI drivers".  note that i didn't touch libGL.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Feb 2005 10:27

[Bug 2428] Remove useless #ifdef GLX_DIRECT_RENDERING from drivers

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=2428          

alanh <at> fairlite.demon.co.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

------- Additional Comments From alanh <at> fairlite.demon.co.uk  2005-02-01 01:27 -------
Gotcha. I remember now.          

     
--           
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: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Permalink | Reply | 0 comments |
headers
Daniel Sperka | 1 Feb 2005 18:23
Picon

Need buffer swap counts

I am using mesa-solo in an application that attempts to generate simple 
3d scenes at the full frame rate of the video card. I use an /etc/drirc 
file with the following option for my app:

<option name="vblank_mode" value="3"/>

this option is supposed to synchronize the swap to the VBLANK period. 
Based on my reading of the code, and based on actual measurements this 
works as advertised, and quite well.

I want to KNOW FOR CERTAIN that the swap occurred for a given frame, and 
that it didn't skip a frame or two in the process. When that happens, I 
need to know how many frames were missed.  In some instances we use 
/dev/rtc for an independent measurement, but we cannot always rely on 
that solution.

Under ordinary X, there is GLX_OML_sync_control, which provides methods 
to determine whether frame(s) were missed.

In the miniglx interface this extension doesn't exist, and the various 
methods - like queryFrameTracking -- which would answer my questions are 
all hidden in opaque structs (opaque to a client app, at least). In 
particular, 'queryFrameTracking' is a member of 'DRIdrawable', but that 
struct is opaque to a glX client application like mine (it is defined in 
miniglxP.h).

Can anyone tell me if

a) I am wrong, i.e. "...nope, just call 'thisMethod' from your app, dummy"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Whitwell | 1 Feb 2005 17:48

Re: [Mesa3d-dev] Need buffer swap counts

Daniel Sperka wrote:
> I am using mesa-solo in an application that attempts to generate simple 
> 3d scenes at the full frame rate of the video card. I use an /etc/drirc 
> file with the following option for my app:
> 
> <option name="vblank_mode" value="3"/>
> 
> this option is supposed to synchronize the swap to the VBLANK period. 
> Based on my reading of the code, and based on actual measurements this 
> works as advertised, and quite well.
> 
> I want to KNOW FOR CERTAIN that the swap occurred for a given frame, and 
> that it didn't skip a frame or two in the process. When that happens, I 
> need to know how many frames were missed.  In some instances we use 
> /dev/rtc for an independent measurement, but we cannot always rely on 
> that solution.
> 
> Under ordinary X, there is GLX_OML_sync_control, which provides methods 
> to determine whether frame(s) were missed.

The work for the above is all done in the r200_dri.so and the drm 
driver, ie the code which is (more or less) shared with mesa-solo.

Probably everything is in place for this extension, you just need to 
hook it up and enable it in Mesa-solo.

Keith

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Romanick | 1 Feb 2005 18:06
Picon
Favicon

Re: Need buffer swap counts

Daniel Sperka wrote:

> Under ordinary X, there is GLX_OML_sync_control, which provides methods 
> to determine whether frame(s) were missed.

You might also look at GLX_MESA_swap_frame_usage.

Basically, the libGL code to support these functions needs to be ported 
to miniglx.  Looking in src/glx/x11/glxcmds.c, it appears that this code 
is pretty simple.  It shouldn't be too difficult to port.

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Feb 2005 19:08

[Bug 2466] New: application gives seg fault, error in glutGetWindow in libglut.so.3.7.1

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=2466          

           Summary: application gives seg fault, error in glutGetWindow in
                    libglut.so.3.7.1
           Product: Mesa
           Version: 6.2.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: GLUT
        AssignedTo: mesa3d-dev <at> lists.sourceforge.net
        ReportedBy: sandreas41 <at> yahoo.com

linux-x86
gcc 3.3.2
kernel 2.4.23

after successful make (despite many warnings)
and install of Mesa, followed by install of NVIDIA-6111
replacing libGL and glx*.h where conflicts exist:
/usr/lib
/usr/local/lib
/usr/local/include/GL

Now, a couple applications give Segmentation Faults
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Feb 2005 19:43

[Bug 2466] application gives seg fault, error in glutGetWindow in libglut.so.3.7.1

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=2466          

------- Additional Comments From sandreas41 <at> yahoo.com  2005-02-03 10:43 -------
oops, something got cut off, here is the patch again.

****** ---- cut ---- *****
--- Mesa-6.2.1/src/glut/glx/glut_win.c  Wed Feb 12 15:56:23 2003
+++ MesaChanged/Mesa-6.2.1/src/glut/glx/glut_win.c     Thu Feb  3 09:45:38 2005
 <at>  <at>  -40,6 +40,11  <at>  <at> 
 static int numRequiredWindowCriteria = sizeof(requiredWindowCriteria) / sizeof(
Criterion);
 static int requiredWindowCriteriaMask = (1 << LEVEL) | (1 << TRANSPARENT);

+/* -------- added header: ----------------------- */
+#include <unistd.h>
+static struct timeval toGUTS = {0,0};
+/* ----------------------------------- StevenA -- */
+
 static void
 cleanWindowWorkList(GLUTwindow * window)
 {
 <at>  <at>  -134,6 +139,7  <at>  <at> 
 glutGetWindow(void)
 {
   if (__glutCurrentWindow) {
+    select(0, NULL, NULL, NULL, &toGUTS);
     return __glutCurrentWindow->num + 1;
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Feb 2005 22:29

[Bug 2466] application gives seg fault, error in glutGetWindow in libglut.so.3.7.1

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=2466          

------- Additional Comments From brian.paul <at> tungstengraphics.com  2005-02-03 13:29 -------
I highly doubt this is a timing issue in GLUT.

I'd recompile GLUT with debugging info, see if it crashes, then use gdb to get a
stack trace.  Basically:

cd Mesa-6.2/
make realclean
make linux-debug

Then, copy the lib/libglut.* files to wherever you need them and try your app again.          

     
--           
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: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 4 Feb 2005 02:06

[Bug 2466] application gives seg fault, error in glutGetWindow in libglut.so.3.7.1

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=2466          

------- Additional Comments From sandreas41 <at> yahoo.com  2005-02-03 17:06 -------
Adding debug caused the seg fault to not occur. 

So I did a backtrace on the non-debug version of libglut.so.3.7.1
(gdb) run
Starting program: /usr/local/bin/Atlas
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 2502)]
Please wait while loading databases...done.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 2502)]
0x40044533 in glutGetWindow () from /usr/local/lib/libglut.so.3
Current language:  auto; currently c
(gdb) bt
#0  0x40044533 in glutGetWindow () from /usr/local/lib/libglut.so.3
#1  0xbffff2d8 in ?? ()
#2  0x0807fab1 in puGetWindow () at pu.cxx:60
#3  0x0807fab1 in puGetWindow () at pu.cxx:60
#4  0x080844c0 in puObject (this=0x8122468, minx=1, miny=0, maxx=0, maxy=0)
    at puObject.cxx:155
#5  0x0807ff1b in puRealInit () at pu.h:871
#6  0x0804fe9c in init_gui (textureFonts=true) at /usr/include/plib/puGLUT.h:67
#7  0x08052ca0 in main (argc=1, argv=0xbffff6f4) at Atlas.cxx:1097
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Whitwell | 4 Feb 2005 09:36

Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

Felix Kuehling wrote:
> CVSROOT:	/cvs/mesa
> Module name:	Mesa
> Repository:	Mesa/src/mesa/drivers/dri/savage/
> Changes by:	fxkuehl <at> gabe.	05/02/03 16:25:41
> 
> Log message:
>   Added an option texture_heaps that allows selecting which texture heaps
>   will be used. Implemented this option in the Savage driver. On my
>   ProSavageDDR uploads to AGP memory are about 1.5 times as fast as
>   uploads to card memory. On non-IGP hardware the difference may be even
>   bigger. Now mplayer -gl is getting really usable.

Felix,

What sort of numbers for texture download are you seeing?

Keith

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Permalink | Reply | 1 comment |

Gmane