Menu
▾
▴
chromium-dev
|
From: Mike H. <mho...@gr...> - 2004-07-17 23:10:33
|
I very happy to announce that Raptor, the parallel volume rendering system written at Stanford using Chromium, has been released. http://graphics.stanford.edu/raptor The source code, (limited) documentation, and some (large) datasets are available. Give it a go and let me know if there are any issues. This has not been thoroughly tested on Nvidia based clusters, so I'm curious how that will go. -Mike |
|
From: Mike H. <mho...@gr...> - 2004-07-19 17:25:28
|
Hmmm... For linux, I use glXGetProcAddress which should be everywhere. On windows, wglGetProcAddress *should* work. Does anyone know what the standard really is here? If GetProcAddressARB works for everyone, that's an easy code fix. Dave: Which lines in the raptor code are you changing? Thanks, Mike David Jones wrote: > Ok, now I got it working. It seemed like GetProcAddress isn't in my GL > distro, but GetProcAddressARB is. Since GetProcAddress is defined in the > linked cr libs, that was getting invoked and subsequentally calling the > chromium stuff. > > So a non-cr run of raptor *does* work for me when I change GetProcAddress > to GetProcAddressARB. > > Weird. > > -Dave > > > On Mon, 19 Jul 2004, Mike Houston wrote: > > >>If you don't feed it "CR" at the end of the command line, there should >>be no chromium stuff loaded. At least it runs that way for me. Are you >>using Nvidia's GL library or Chromium's? >> >>-Mike >> >>David Jones wrote: >> >> >>>I started that from the command line - no mothership. Since it's linked >>>against the Cr libs, I'm guessing that the crfaker lib is invoking its >>>opengl stub stuff. >>> >>>I don't know a way of getting around this without fiddling with raptor >>>code.. >>> >>>-Dave >>> >>> >>>On Mon, 19 Jul 2004, Mike Houston wrote: >>> >>> >>> >>>>Can you send me a run not using Chromium? >>>> >>>>-Mike >>>> >>>>David Jones wrote: >>>> >>>> >>>> >>>>>Yeah, this is an FX board (5900 Ultra on Linux) that supports >>>>>GL_ARB_fragment_program and GL_ARB_vertex_program. >>>>> >>>>>I've attached the output of a run. I double checked the paths to >>>>>everything and those seem to look ok. >>>>> >>>>>-Dave >>>>> >>>>>On Mon, 19 Jul 2004, Mike Houston wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>I'm willing to bet the some of the extensions failed to load, but it >>>>>>should have assert failed... What type of Nvidia board is it? Raptor >>>>>>requires an NV30+. There are some known issues with the latest Nvidia >>>>>>drivers, but they shouldn't be causing failures with local rendering. >>>>>> >>>>>>Can you send me the output of Raptor please? I'll try to take a guess >>>>>>at what I might think is happening. When I get back in town, I'll try >>>>>>to track down an Nvidia board I can run in my Linux box and see if I can >>>>>>track down these errors. Things seem to work fine with Nvidia hardware >>>>>>under Windows... >>>>>> >>>>>>-Mike >>>>>> >>>>>> >>>>>>David Jones wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I gave this a shot on some of our machines. Running it locally without >>>>>>>any chromium gives me a blank window. Running the raptor_1.conf config >>>>>>>starts the app. but quickly bails with the crserver dumping: >>>>>>> >>>>>>>CR Debug(nitrogen:3568): Done calling crTCPIPConnection >>>>>>>CR Debug(nitrogen:3568): Done connecting to server. >>>>>>>CR Debug(nitrogen:3568): Received a drawable: 35651585 >>>>>>>X Error of failed request: BadMatch (invalid parameter attributes) >>>>>>>Major opcode of failed request: 144 (GLX) >>>>>>>Minor opcode of failed request: 5 (X_GLXMakeCurrent) >>>>>>>Serial number of failed request: 30 >>>>>>>Current serial number in output stream: 30 >>>>>>> >>>>>>>I've tried the raptor_1.conf with both a local and remote 'crappfaker'. >>>>>>>I'm using a Nvidia 5900 Ultra with the 61.06 Linux drivers. >>>>>>> >>>>>>>I've also run raptor on my home desktop (Radeon 9600) under windows and it >>>>>>>seems to work fine there. >>>>>>> >>>>>>>-Dave >>>>>>> >>>>>>> >>>>>>>On Sat, 17 Jul 2004, Mike Houston wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>I very happy to announce that Raptor, the parallel volume rendering >>>>>>>>system written at Stanford using Chromium, has been released. >>>>>>>> >>>>>>>>http://graphics.stanford.edu/raptor >>>>>>>> >>>>>>>>The source code, (limited) documentation, and some (large) datasets are >>>>>>>>available. Give it a go and let me know if there are any issues. This >>>>>>>>has not been thoroughly tested on Nvidia based clusters, so I'm curious >>>>>>>>how that will go. >>>>>>>> >>>>>>>>-Mike >>>>>>>> >>>>>>>> >>>>>>>>------------------------------------------------------- >>>>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop >>>>>>>>FREE Java Enterprise J2EE developer tools! >>>>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today. >>>>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >>>>>>>>_______________________________________________ >>>>>>>>Chromium-dev mailing list >>>>>>>>Chr...@li... >>>>>>>>https://lists.sourceforge.net/lists/listinfo/chromium-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>------------------------------------------------------- >>>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop >>>>>>>FREE Java Enterprise J2EE developer tools! >>>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today. >>>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >>>>>>>_______________________________________________ >>>>>>>Chromium-users mailing list >>>>>>>Chr...@li... >>>>>>>https://lists.sourceforge.net/lists/listinfo/chromium-users >>>>>> >> |
|
From: Mike H. <mho...@gr...> - 2004-07-19 17:29:53
|
I just reread the GLX_ARB_get_proc_address extension. Obviously, I should be using that... Why Chromium is choking on a bad drawable is a separate issue... That one I'll probably need help tracking since I don't have an Nvidia cluster to test on. -Mike Mike Houston wrote: > Hmmm... For linux, I use glXGetProcAddress which should be everywhere. > On windows, wglGetProcAddress *should* work. Does anyone know what the > standard really is here? > > If GetProcAddressARB works for everyone, that's an easy code fix. > > Dave: Which lines in the raptor code are you changing? > > Thanks, > Mike > > David Jones wrote: > >> Ok, now I got it working. It seemed like GetProcAddress isn't in my >> GL distro, but GetProcAddressARB is. Since GetProcAddress is defined >> in the linked cr libs, that was getting invoked and subsequentally >> calling the chromium stuff. >> >> So a non-cr run of raptor *does* work for me when I change >> GetProcAddress to GetProcAddressARB. >> >> Weird. >> >> -Dave >> >> >> On Mon, 19 Jul 2004, Mike Houston wrote: >> >> >>> If you don't feed it "CR" at the end of the command line, there >>> should be no chromium stuff loaded. At least it runs that way for >>> me. Are you using Nvidia's GL library or Chromium's? >>> >>> -Mike >>> >>> David Jones wrote: >>> >>> >>>> I started that from the command line - no mothership. Since it's >>>> linked against the Cr libs, I'm guessing that the crfaker lib is >>>> invoking its opengl stub stuff. >>>> >>>> I don't know a way of getting around this without fiddling with >>>> raptor code.. >>>> >>>> -Dave >>>> >>>> >>>> On Mon, 19 Jul 2004, Mike Houston wrote: >>>> >>>> >>>> >>>>> Can you send me a run not using Chromium? >>>>> >>>>> -Mike >>>>> >>>>> David Jones wrote: >>>>> >>>>> >>>>> >>>>>> Yeah, this is an FX board (5900 Ultra on Linux) that supports >>>>>> GL_ARB_fragment_program and GL_ARB_vertex_program. >>>>>> >>>>>> I've attached the output of a run. I double checked the paths to >>>>>> everything and those seem to look ok. >>>>>> >>>>>> -Dave >>>>>> >>>>>> On Mon, 19 Jul 2004, Mike Houston wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I'm willing to bet the some of the extensions failed to load, but >>>>>>> it should have assert failed... What type of Nvidia board is >>>>>>> it? Raptor requires an NV30+. There are some known issues with >>>>>>> the latest Nvidia drivers, but they shouldn't be causing failures >>>>>>> with local rendering. >>>>>>> >>>>>>> Can you send me the output of Raptor please? I'll try to take a >>>>>>> guess at what I might think is happening. When I get back in >>>>>>> town, I'll try to track down an Nvidia board I can run in my >>>>>>> Linux box and see if I can track down these errors. Things seem >>>>>>> to work fine with Nvidia hardware under Windows... >>>>>>> >>>>>>> -Mike >>>>>>> >>>>>>> >>>>>>> David Jones wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I gave this a shot on some of our machines. Running it locally >>>>>>>> without any chromium gives me a blank window. Running the >>>>>>>> raptor_1.conf config starts the app. but quickly bails with the >>>>>>>> crserver dumping: >>>>>>>> >>>>>>>> CR Debug(nitrogen:3568): Done calling crTCPIPConnection >>>>>>>> CR Debug(nitrogen:3568): Done connecting to server. >>>>>>>> CR Debug(nitrogen:3568): Received a drawable: 35651585 >>>>>>>> X Error of failed request: BadMatch (invalid parameter attributes) >>>>>>>> Major opcode of failed request: 144 (GLX) >>>>>>>> Minor opcode of failed request: 5 (X_GLXMakeCurrent) >>>>>>>> Serial number of failed request: 30 >>>>>>>> Current serial number in output stream: 30 >>>>>>>> >>>>>>>> I've tried the raptor_1.conf with both a local and remote >>>>>>>> 'crappfaker'. I'm using a Nvidia 5900 Ultra with the 61.06 >>>>>>>> Linux drivers. >>>>>>>> >>>>>>>> I've also run raptor on my home desktop (Radeon 9600) under >>>>>>>> windows and it seems to work fine there. >>>>>>>> >>>>>>>> -Dave >>>>>>>> >>>>>>>> >>>>>>>> On Sat, 17 Jul 2004, Mike Houston wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I very happy to announce that Raptor, the parallel volume >>>>>>>>> rendering system written at Stanford using Chromium, has been >>>>>>>>> released. >>>>>>>>> >>>>>>>>> http://graphics.stanford.edu/raptor >>>>>>>>> >>>>>>>>> The source code, (limited) documentation, and some (large) >>>>>>>>> datasets are available. Give it a go and let me know if there >>>>>>>>> are any issues. This has not been thoroughly tested on Nvidia >>>>>>>>> based clusters, so I'm curious how that will go. >>>>>>>>> >>>>>>>>> -Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------- >>>>>>>>> This SF.Net email is sponsored by BEA Weblogic Workshop >>>>>>>>> FREE Java Enterprise J2EE developer tools! >>>>>>>>> Get your free copy of BEA WebLogic Workshop 8.1 today. >>>>>>>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >>>>>>>>> _______________________________________________ >>>>>>>>> Chromium-dev mailing list >>>>>>>>> Chr...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------- >>>>>>>> This SF.Net email is sponsored by BEA Weblogic Workshop >>>>>>>> FREE Java Enterprise J2EE developer tools! >>>>>>>> Get your free copy of BEA WebLogic Workshop 8.1 today. >>>>>>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >>>>>>>> _______________________________________________ >>>>>>>> Chromium-users mailing list >>>>>>>> Chr...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/chromium-users >>>>>>> >>>>>>> >>> > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev |
|
From: David J. <jo...@mc...> - 2004-07-19 17:32:43
|
I only changed one line in raptor.cpp (225): #define GETPROCADDRESS(x) glXGetProcAddress((const GLubyte*) x) to #define GETPROCADDRESS(x) glXGetProcAddressARB((const GLubyte*) x) I also did a 'strings /usr/lib/libGL.so', and the only glXGetProcAddress that was listed was glXGetProcAddressARB (ie: nothing listed with the ARB stripped). -Dave On Mon, 19 Jul 2004, Mike Houston wrote: > Hmmm... For linux, I use glXGetProcAddress which should be everywhere. > On windows, wglGetProcAddress *should* work. Does anyone know what > the standard really is here? > > If GetProcAddressARB works for everyone, that's an easy code fix. > > Dave: Which lines in the raptor code are you changing? > > Thanks, > Mike > > David Jones wrote: > > > Ok, now I got it working. It seemed like GetProcAddress isn't in my GL > > distro, but GetProcAddressARB is. Since GetProcAddress is defined in the > > linked cr libs, that was getting invoked and subsequentally calling the > > chromium stuff. > > > > So a non-cr run of raptor *does* work for me when I change GetProcAddress > > to GetProcAddressARB. > > > > Weird. > > > > -Dave > > > > > > On Mon, 19 Jul 2004, Mike Houston wrote: > > > > > >>If you don't feed it "CR" at the end of the command line, there should > >>be no chromium stuff loaded. At least it runs that way for me. Are you > >>using Nvidia's GL library or Chromium's? > >> > >>-Mike > >> > >>David Jones wrote: > >> > >> > >>>I started that from the command line - no mothership. Since it's linked > >>>against the Cr libs, I'm guessing that the crfaker lib is invoking its > >>>opengl stub stuff. > >>> > >>>I don't know a way of getting around this without fiddling with raptor > >>>code.. > >>> > >>>-Dave > >>> > >>> > >>>On Mon, 19 Jul 2004, Mike Houston wrote: > >>> > >>> > >>> > >>>>Can you send me a run not using Chromium? > >>>> > >>>>-Mike > >>>> > >>>>David Jones wrote: > >>>> > >>>> > >>>> > >>>>>Yeah, this is an FX board (5900 Ultra on Linux) that supports > >>>>>GL_ARB_fragment_program and GL_ARB_vertex_program. > >>>>> > >>>>>I've attached the output of a run. I double checked the paths to > >>>>>everything and those seem to look ok. > >>>>> > >>>>>-Dave > >>>>> > >>>>>On Mon, 19 Jul 2004, Mike Houston wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>I'm willing to bet the some of the extensions failed to load, but it > >>>>>>should have assert failed... What type of Nvidia board is it? Raptor > >>>>>>requires an NV30+. There are some known issues with the latest Nvidia > >>>>>>drivers, but they shouldn't be causing failures with local rendering. > >>>>>> > >>>>>>Can you send me the output of Raptor please? I'll try to take a guess > >>>>>>at what I might think is happening. When I get back in town, I'll try > >>>>>>to track down an Nvidia board I can run in my Linux box and see if I can > >>>>>>track down these errors. Things seem to work fine with Nvidia hardware > >>>>>>under Windows... > >>>>>> > >>>>>>-Mike > >>>>>> > >>>>>> > >>>>>>David Jones wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>I gave this a shot on some of our machines. Running it locally without > >>>>>>>any chromium gives me a blank window. Running the raptor_1.conf config > >>>>>>>starts the app. but quickly bails with the crserver dumping: > >>>>>>> > >>>>>>>CR Debug(nitrogen:3568): Done calling crTCPIPConnection > >>>>>>>CR Debug(nitrogen:3568): Done connecting to server. > >>>>>>>CR Debug(nitrogen:3568): Received a drawable: 35651585 > >>>>>>>X Error of failed request: BadMatch (invalid parameter attributes) > >>>>>>>Major opcode of failed request: 144 (GLX) > >>>>>>>Minor opcode of failed request: 5 (X_GLXMakeCurrent) > >>>>>>>Serial number of failed request: 30 > >>>>>>>Current serial number in output stream: 30 > >>>>>>> > >>>>>>>I've tried the raptor_1.conf with both a local and remote 'crappfaker'. > >>>>>>>I'm using a Nvidia 5900 Ultra with the 61.06 Linux drivers. > >>>>>>> > >>>>>>>I've also run raptor on my home desktop (Radeon 9600) under windows and it > >>>>>>>seems to work fine there. > >>>>>>> > >>>>>>>-Dave > >>>>>>> > >>>>>>> > >>>>>>>On Sat, 17 Jul 2004, Mike Houston wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>I very happy to announce that Raptor, the parallel volume rendering > >>>>>>>>system written at Stanford using Chromium, has been released. > >>>>>>>> > >>>>>>>>http://graphics.stanford.edu/raptor > >>>>>>>> > >>>>>>>>The source code, (limited) documentation, and some (large) datasets are > >>>>>>>>available. Give it a go and let me know if there are any issues. This > >>>>>>>>has not been thoroughly tested on Nvidia based clusters, so I'm curious > >>>>>>>>how that will go. > >>>>>>>> > >>>>>>>>-Mike > >>>>>>>> > >>>>>>>> > >>>>>>>>------------------------------------------------------- > >>>>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop > >>>>>>>>FREE Java Enterprise J2EE developer tools! > >>>>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today. > >>>>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > >>>>>>>>_______________________________________________ > >>>>>>>>Chromium-dev mailing list > >>>>>>>>Chr...@li... > >>>>>>>>https://lists.sourceforge.net/lists/listinfo/chromium-dev > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>------------------------------------------------------- > >>>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop > >>>>>>>FREE Java Enterprise J2EE developer tools! > >>>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today. > >>>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > >>>>>>>_______________________________________________ > >>>>>>>Chromium-users mailing list > >>>>>>>Chr...@li... > >>>>>>>https://lists.sourceforge.net/lists/listinfo/chromium-users > >>>>>> > >> > > |
|
From: Mike H. <mho...@gr...> - 2004-07-19 17:45:39
|
Includes David's glXGetProcAddress bug fix. I should have been using the ARB version... There is still a bug with Nvidia hardware in sort-last cluster rendering mode to still track down. It's throwing a invalid drawable error. Since the local rendering version works, this looks like an odd interaction between Chromium and Nvidia's Linux drivers doing sort-last rendering. -Mike |
|
From: David J. <jo...@mc...> - 2004-07-19 18:47:30
|
So there is a 'partial' fix to this. Commenting out both
renderspu.Conf('render_to_app_window', 1 )
renderspu.Conf('render_to_crut_window', 1 )
in the config file fixes things.
As best I can tell, the glXMakeCurrent calls made at around line 1120 in
renderspu_glx.c are freaking out. Unfortunately, I don't really know
enough about this code to know what's going on.
-Dave
On Mon, 19 Jul 2004, Mike Houston wrote:
> Includes David's glXGetProcAddress bug fix. I should have been using
> the ARB version...
>
> There is still a bug with Nvidia hardware in sort-last cluster rendering
> mode to still track down. It's throwing a invalid drawable error.
> Since the local rendering version works, this looks like an odd
> interaction between Chromium and Nvidia's Linux drivers doing sort-last
> rendering.
>
> -Mike
>
>
|
|
From: Ricky Uy <ric...@ya...> - 2004-07-19 20:21:50
|
There have been several posts about a "memory access violation" error when people try to use the tilesort spu. It is because of this that I began using the pack->tilesort->render configuration as a workaround. I found the problem, however, and here is a patch. Put this after line 333 in tilesort_window.c:
/* this should be line 333 */ winInfo->lastY = r.top;
if(winInfo->lastWidth == 0 || winInfo->lastHeight == 0)
{
if (tilesort_spu.fakeWindowWidth != 0)
{
winInfo->lastWidth = tilesort_spu.fakeWindowWidth;
winInfo->lastHeight = tilesort_spu.fakeWindowHeight;
}
}
Basically, winInfo->client_wnd is sometimes not NULL, but still currently an invalid handle for purposes of retrieving the window size because the window has not yet been initialized. In this case, the lastWidth and lastHeight variables are going to be 0, and they are never set to the fake_window_dims parameters because it never fell into the if(!winInfo->client) branch. This patch fixes that. This is all application dependent due to the way different applications set up their windows, so that's why it worked before with some programs but not with others.
You should now be able to do a straight tilesort->render configuration in Windows. Hope this helps some of you out.
Ricky
---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign! |
|
From: Brian P. <bri...@tu...> - 2004-07-20 20:46:27
|
Ricky Uy wrote:
> There have been several posts about a "memory access violation" error
> when people try to use the tilesort spu. It is because of this that I
> began using the pack->tilesort->render configuration as a workaround. I
> found the problem, however, and here is a patch. Put this after line 333
> in tilesort_window.c:
>
> /* this should be line 333 */ winInfo->lastY = r.top;
>
> if(winInfo->lastWidth == 0 || winInfo->lastHeight == 0)
> {
> if (tilesort_spu.fakeWindowWidth != 0)
> {
> winInfo->lastWidth = tilesort_spu.fakeWindowWidth;
>
> winInfo->lastHeight = tilesort_spu.fakeWindowHeight;
> }
> }
>
> Basically, winInfo->client_wnd is sometimes not NULL, but still
> currently an invalid handle for purposes of retrieving the window size
> because the window has not yet been initialized. In this case, the
> lastWidth and lastHeight variables are going to be 0, and they are never
> set to the fake_window_dims parameters because it never fell into the
> if(!winInfo->client) branch. This patch fixes that. This is all
> application dependent due to the way different applications set up their
> windows, so that's why it worked before with some programs but not with
> others.
>
> You should now be able to do a straight tilesort->render configuration
> in Windows. Hope this helps some of you out.
I'm checking in the fix, Ricky. Thanks.
-Brian
|
|
From: Mike H. <mho...@gr...> - 2004-07-19 19:11:32
|
Hmmm, that will prevent interaction from working. But, it sounds like
we will need to find a workaround for the Nvidia drivers and
glXMakeCurrent. What happens if you just comment out render_to_app_window?
-Mike
David Jones wrote:
> So there is a 'partial' fix to this. Commenting out both
>
> renderspu.Conf('render_to_app_window', 1 )
> renderspu.Conf('render_to_crut_window', 1 )
>
> in the config file fixes things.
>
> As best I can tell, the glXMakeCurrent calls made at around line 1120 in
> renderspu_glx.c are freaking out. Unfortunately, I don't really know
> enough about this code to know what's going on.
>
> -Dave
>
>
> On Mon, 19 Jul 2004, Mike Houston wrote:
>
>
>>Includes David's glXGetProcAddress bug fix. I should have been using
>>the ARB version...
>>
>>There is still a bug with Nvidia hardware in sort-last cluster rendering
>>mode to still track down. It's throwing a invalid drawable error.
>>Since the local rendering version works, this looks like an odd
>>interaction between Chromium and Nvidia's Linux drivers doing sort-last
>>rendering.
>>
>>-Mike
>>
>>
|
|
From: David J. <jo...@mc...> - 2004-07-19 19:28:08
|
Actually, the 'render_to_crut_window' causes the X error. I'm not sure
how the 'render_to_app_window' option behaves in a sort-last
configuration.
By commenting out both, I get the renderspu window and a null rendered
crut server winodw that grabs events. So I can still interact, it's just
in the render window.
-Dave
On Mon, 19 Jul 2004, Mike Houston wrote:
> Hmmm, that will prevent interaction from working. But, it sounds like
> we will need to find a workaround for the Nvidia drivers and
> glXMakeCurrent. What happens if you just comment out render_to_app_window?
>
> -Mike
>
> David Jones wrote:
> > So there is a 'partial' fix to this. Commenting out both
> >
> > renderspu.Conf('render_to_app_window', 1 )
> > renderspu.Conf('render_to_crut_window', 1 )
> >
> > in the config file fixes things.
> >
> > As best I can tell, the glXMakeCurrent calls made at around line 1120 in
> > renderspu_glx.c are freaking out. Unfortunately, I don't really know
> > enough about this code to know what's going on.
> >
> > -Dave
> >
> >
> > On Mon, 19 Jul 2004, Mike Houston wrote:
> >
> >
> >>Includes David's glXGetProcAddress bug fix. I should have been using
> >>the ARB version...
> >>
> >>There is still a bug with Nvidia hardware in sort-last cluster rendering
> >>mode to still track down. It's throwing a invalid drawable error.
> >>Since the local rendering version works, this looks like an odd
> >>interaction between Chromium and Nvidia's Linux drivers doing sort-last
> >>rendering.
> >>
> >>-Mike
> >>
> >>
>
>
|
|
From: Alan M. <al...@re...> - 2004-07-19 22:16:22
|
On Mon, 2004-07-19 at 15:27, David Jones wrote:
> Actually, the 'render_to_crut_window' causes the X error. I'm not sure
> how the 'render_to_app_window' option behaves in a sort-last
> configuration.
>
> By commenting out both, I get the renderspu window and a null rendered
> crut server winodw that grabs events. So I can still interact, it's just
> in the render window.
>
> -Dave
>
Yep. That's what I get. It works once I comment out those two lines.
>
> On Mon, 19 Jul 2004, Mike Houston wrote:
>
> > Hmmm, that will prevent interaction from working. But, it sounds like
> > we will need to find a workaround for the Nvidia drivers and
> > glXMakeCurrent. What happens if you just comment out render_to_app_window?
> >
> > -Mike
> >
> > David Jones wrote:
> > > So there is a 'partial' fix to this. Commenting out both
> > >
> > > renderspu.Conf('render_to_app_window', 1 )
> > > renderspu.Conf('render_to_crut_window', 1 )
> > >
> > > in the config file fixes things.
> > >
> > > As best I can tell, the glXMakeCurrent calls made at around line 1120 in
> > > renderspu_glx.c are freaking out. Unfortunately, I don't really know
> > > enough about this code to know what's going on.
> > >
> > > -Dave
> > >
> > >
> > > On Mon, 19 Jul 2004, Mike Houston wrote:
> > >
> > >
> > >>Includes David's glXGetProcAddress bug fix. I should have been using
> > >>the ARB version...
> > >>
> > >>There is still a bug with Nvidia hardware in sort-last cluster rendering
> > >>mode to still track down. It's throwing a invalid drawable error.
> > >>Since the local rendering version works, this looks like an odd
> > >>interaction between Chromium and Nvidia's Linux drivers doing sort-last
> > >>rendering.
> > >>
> > >>-Mike
> > >>
> > >>
> >
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
--
Alan Matsuoka
Global Professional Services
Red Hat Canada, Ltd
mailto:al...@re...
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X